UseSystemd can detect an interactive shell as `running as systemd service`

[Tragetaschen]

Describe the bug

I have my embedded platform and configure the IHostBuilder to .UseSystemd().

1. Using the application as systemd service always works correctly.
2. When I log into my system using SSH, I can run my application on the interactive prompt and it's using ConsoleLifetime and console logging format.
3. When I use the tty on the serial port to run the application, that's detected as systemd environment and I get the systemd log format and termination behavior (no SIGINT handler)

The reason for the latter case is that my bash instance on the serial port inherits the INVOCATION_ID environment variable through login:

# env
LANG=C.UTF-8
OLDPWD=/
INVOCATION_ID=5561c5304f434119a45c4b6f260f1b00
EDITOR=vi
XDG_SESSION_ID=c1
HUSHLOGIN=FALSE
USER=root
PWD=/root
HOME=/root
JOURNAL_STREAM=8:13520
XDG_SESSION_TYPE=tty
MAIL=/var/spool/mail/root
SHELL=/bin/sh
TERM=putty
XDG_SESSION_CLASS=user
SHLVL=1
LOGNAME=root
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/0/bus
XDG_RUNTIME_DIR=/run/user/0
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
PS1=\u@\h:\w\$
_=/usr/bin/env
# pstree
systemd-+-…
        |-login---sh---pstree
…

[analogrelay]

@tmds do you have thoughts here? You're our semi-resident systemd expert ;). We can take a look as well but you might have some insight here.

[analogrelay]

Looking in to this deeper, it looks like a tricky situation. Right now we're using the INVOCATION_ID as the primary detector. If it's present, we don't look deeper, but if the shell is started from systemd, the env vars will flow from process to process.

We do have our fallback detection logic that looks at /proc/[pid]/comm, but some sources show that to be risky at times.

One option is, of course, to perform your own validation and use that to determine whether to call UseSystemd.

[tmds]

@anurse I had missed your notification.
I will take a closer look.

Strange enough, INVOCATION_ID is even set when I run an interactive terminal on my Fedora 31. I'm pretty sure this wasn't always like this.

[tmds]

To fix this, we could check if the process itself or any of its parents is a terminal. If that is the case, we're not a systemd service.
Something like this:

        private static bool HasTtyInProcessTree()
        {
            if (!Console.IsErrorRedirected)
            {
                return true;
            }
            else
            {
                int myPid = Process.GetCurrentProcess().Id;
                int? ppid = GetPPid(myPid);
                if (ppid.HasValue)
                {
                    return HasTtyInProcessTree(ppid.Value);
                }
            }

            return false;
        }

        private static bool HasTtyInProcessTree(int pid)
        {
            if (pid == 0)
            {
                return false;
            }

            if (IsATty($"/proc/{pid}/fd/2"))
            {
                return true;
            }
            else
            {
                int? ppid = GetPPid(pid);
                if (ppid.HasValue)
                {
                    return HasTtyInProcessTree(ppid.Value);
                }
            }

            return false;
        }

        private static int? GetPPid(int pid)
        {
            try
            {
                string statContent = File.ReadAllText($"/proc/{pid}/stat");
                int pidStart = statContent.IndexOf(") ") + 4;
                int pidEnd = statContent.IndexOf(" ", pidStart);
                System.Console.WriteLine($"'{statContent.Substring(pidStart, pidEnd - pidStart)}'");
                return int.Parse(statContent.Substring(pidStart, pidEnd - pidStart), CultureInfo.InvariantCulture);
            }
            catch
            {
                return null;
            }
        }

        private static bool IsATty(int fd)
        {
            try
            {
                return isatty(fd) == 1;
            }
            catch
            {
                return false;
            }
        }

        private static bool IsATty(string filename)
        {
            try
            {
                using (var filestream = new FileStream(filename, FileMode.Open, FileAccess.Read))
                {
                    return IsATty(filestream.SafeFileHandle.DangerousGetHandle().ToInt32());
                }
            }
            catch
            {
                return false;
            }
        }

        [DllImport("libc", SetLastError = true)]
        private static extern int isatty(int fd);

@anurse wdyt?
@onyxmaster do you have some thoughts on the issue, or suggested solution?

[onyxmaster]

I wonder if redirected input/output should be considered as the "terminal" case.

Maybe drop the INVOCATION_ID check altogether and always go through the "slow" path with detecting the name of the parent process? Yes, I see that parent pid might actually be not named with systemd, but it looks less complex.

Also, checking the TERM envvar might be useful, if it's not empty, it usually means that there is some terminal is attached to the session.

[Tragetaschen]

Would INVOCATION_ID != null && GetPPid() == 1 work as detector for systemd?

[onyxmaster]

@Tragetaschen no, since it would not handle the user units. Also, if systemd is not an init process it would be a false positive. Take a look at the current implementation, we could skip the current short-circuit with INVOCATION_ID presence check, but I'm still not sure if it is the right way (see my previous comment).

[Tragetaschen]

Ah, forgot about user units

[tmds]

Maybe drop the INVOCATION_ID check altogether and always go through the "slow" path with detecting the name of the parent process

I'm not concerned with the speed. This does require the systemd process to be the direct parent. Maybe that is ok.

[tmds]

checking the TERM envvar might be useful

And a much simpler check than what I had in mind.

[analogrelay]

I'm not concerned with the speed.

I concur. This is a one-time check at app startup. "Slow" is very relative here. Perhaps a rough measurement would be useful, but I'm not worried. The parent process check seems right to me.

I think we should also add some kind of override. For example UseSystemd(bool force). If force is true, the check is skipped and we assume the service is a Systemd service. That way we could be a little more conservative and users could always force it on in other places. Users already have a workaround for adding custom "disable" logic (add their logic and skip the call to UseSystemd if they don't believe they're in systemd). Adding that would give a way to have custom "enable" logic as well.

[analogrelay]

@tmds Thoughts on the action we take here? To me, checking the parent process name (and providing a force override) seems right. I can find someone to do the work, but I'd appreciate your thoughts as someone with a little more systemd experience 😄.