openrc-user hangs when under tcsh due to closed fds

[te36de]

Current default/linux/amd64/23.0/desktop.

Replacing username in following description with USER

Ran across the issue trying to make xrdp (dilfridge repo or also self-built current xrdp 0.10.4 ebuild) work. Comes with:

/etc/pam.d/xrdp-sesman
auth       include      system-remote-login
account    include      system-remote-login
password   include      system-remote-login
session    include      system-remote-login

So, when starting a session, it call PAM which starts

/run/openrc/init.d/user.USER --lockfd 23 start

Which then through a couple of intermediate programs hangs itself in

/usr/libexec/rc/bin/openrc-user USER

where hanging means that it waits for a TERM signal, which seemingly is what's described as 'lingering' in https://wiki.gentoo.org/wiki/OpenRC. Which ultimately makes xrdp fail because it's not continuing it's code execution path.

Without any xrdp started, i can also reproduce this problem (as root) with

/etc/init.d/user.USER start
 * Caching service dependencies ...          [ ok ]
 * Starting user.USER ...
(hangs)

Hangs in the same place waiting for TERM signal.

Alas, no documentation in the wiki nor any other place about this (how to troubleshoot openrc user lingering, and what is it's expected behavior).

If one is expected to explicitly call this openrc user stuff by explicitly background it, how the heck is a standard PAM application meant to handle this - AFAIK, there was never explicit backgrounding required when calling PAM. And of course, what app is meant to send the TERM ?

Any example application that is gentoo supported and explicitly supporting this openrc user stuff ?

[thesamesam]

What version of OpenRC?

[navi-desu]

where hanging means that it waits for a TERM signal, which seemingly is what's described as 'lingering' in https://wiki.gentoo.org/wiki/OpenRC

it's not lingering, lingering means "keep user services started even if the user logs out" (or, "do not stop user services")

the hanging is a bug, and it could either be on us, or on your .profile/.bash_profile

same question, what openrc version?

[te36de]

sys-apps/openrc-0.62.10

No $HOME/.profile directory

So, what's the theory of operations of the openrc-user program then ?
If it is meant to "hang around" after starting the user services and wait for TERM, then it seems to me that it should background itself before waiting for TERM signal. And then finish up (stopping user services) after receiving TERM signal. Yes/No ?

[navi-desu]

So, what's the theory of operations of the openrc-user program then ?

• start user services in a non-interactive login shell
• wait for the boot runlevel to finish starting
  • this is done so things like dbus can reliably be started before login continues, since things may use it early at boot (e.g. desktop environments)
• once boot is started, it signals (via writing a '\n' to a pipe on fd3) supervise-daemon to proceed
• openrc-user continues on to start the default runlevel fully in the background
• supervise-daemon will now also finish backgrounding itself, and login will continue

so either, a) your shell is hanging somewhere due to "non-interactive login shell", b) exec($shell, -c, /.../openrc-user.sh) succeeded but returned 0 before executing openrc-user.sh, or c) there's some other bug

[te36de]

I went through the strace of xrdp-sesman and children (-f), and found from openrc-user.sh:

16445 dup2(3, 1)                        = -1 EBADF (Bad file descriptor)  
16445 write(2, "/usr/libexec/rc/sh/openrc-user.sh: line 32: 3: Bad file descriptor\n", 67) = 67  

But that "Bad file description" output from openrc-user.sh was nowhere to be found in any file in /var/log. So that's a bad troubleshooting bug. Errors from that script need to end up in some syslog (IMHO!). Please fix, just in case (IMHO).

FD 3 seems to have been closed way before. I gave up on trying to figure out where in the strace when i got the idea that the culprit might be my user shell - /bin/tcsh:

16443 execve("/bin/tcsh", ["-/bin/tcsh", "-c", "/usr/libexec/rc/sh/openrc-user.sh start"], 0x557d1df652a0 /* 33 vars */ <unfinished ...>

So i changed my login shell to /bin/bash, and e voila:

16981 dup2(3, 1)                        = 1
16981 fcntl(3, F_GETFD)                 = 0
16981 fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
16981 write(1, "\n", 1)                 = 1

And xrdp windows came up.

openrc-user.c:
static bool spawn_openrc(const struct passwd *user, bool start) {
        char *argv0;
        const char *argv[] = {
                NULL /* replaced below */, "-c",
                start ? USER_SH "start" : USER_SH "stop", NULL
        };
        struct exec_result res;
        struct exec_args args;

        /* shell might be a multicall binary, e.g busybox.
         * so setting argv[0] to "-" might not work */
        xasprintf(&argv0, "-%s", user->pw_shell);

I wrote a small program to check just the execve, and indeed, tcsh does close all FD >2 that are open upon startup. And it seems to be the only one from all the shells in /etc/shells that are available from the normal gentoo distro that does this ( i let my program test all of them).

But it still seems weird to me to call the users login shell here. Can you give me one example, how that login shell would have a positive impact ? E.g.: an example of something that would not work, if the shell was simply replaced by /bin/sh instead of user->pw_shell.

[thesamesam]

But that "Bad file description" output from openrc-user.sh was nowhere to be found in any file in /var/log. So that's a bad troubleshooting bug. Errors from that script need to end up in some syslog (IMHO!). Please fix, just in case (IMHO).

It's being worked on. See #783.

tcsh does close all FD >2 that are open upon startup

Indeed, this came up at https://bugs.gentoo.org/962336. We haven't got to the bottom of it yet.

But it still seems weird to me to call the users login shell here. Can you give me one example, how that login shell would have a positive impact ? E.g.: an example of something that would not work, if the shell was simply replaced by /bin/sh instead of user->pw_shell.

It sources the user's ~/.profile to have the same environment when starting any services as they expect for everything else, including any tools or services they may access via that shell in an interactive context.