[3.1.x Backport] IsSystemdService: make check stricter to avoid false positives

[halter73]

Backport of #2734 to 3.1.x

Checking the INVOCATION_ID envvar is causing false positives.
Instead, we now return true only when the direct parent process is 'systemd'.

@tmds @Tragetaschen @anurse @onyxmaster @Tratcher

[analogrelay]

Hrm... in writing the backport request I realized there's a pretty "easy" workaround. You can conditionally call avoid calling [edited for clarity] .UseSystemd based on your own logic (I even remember we covered this in the original issue).

Given that, and the fact that this has a minor breaking change impact, I'm now pretty confident it wouldn't meet the bar.

[tmds]

Hrm... in writing the backport request I realized there's a pretty "easy" workaround. You can conditionally call .UseSystemd based on your own logic

The breaking change is UseSystemd is no-oping in more cases. So calling it won't do anything.

One case that breaks is a user having a script for starting dotnet from the service unit.
He may have to change the script so the dotnet invocation uses the bash 'exec' built-in. Then the dotnet process will be a direct child of systemd (otherwise the shell process sits in-between.)

[tmds]

You can conditionally call .UseSystemd based on your own logic

Ah, I think I should read this as: not-calling it based on your own logic.

For the logic: a heuristic that was suggested in the issue is: only calling UseSystemd when the TERM envvar is not set.

[analogrelay]

Heh, you're right, I wasn't the clearest there :). Updated for clarity.

[analogrelay]

Basically, I don't think this would meet the bar for the 3.1 LTS given the presence of a workaround. I totally support this in 5.0 and we can continue to review the logic for that (and will have previews to get feedback on it and refine it further). Putting it in an LTS patch has a lot more risk associated with it.

[tmds]

@anurse makes sense.

[halter73]

Given the workaround, I agree with @anurse wrt 3.1.x, so I'm closing this.