Log logging errors to stderr instead of stdout, along with setting priority

[onyxmaster]

The rationale behind this change is that in most common scenario with this library being used in a systemd-activated service, the failure to log via journald API is still logged via stdout, and is not assigned the correct severity, which leads to logging failure being undetected by automated monitoring tools.

One of ways to improve on this, is prefixing such messages with SD_ERR priority prefix, along with using stderr for output. On the other hand, adding this prefix in every case seems not robust enough, so I added a couple of checks -- the stderr must be redirected (so running this on console won't have this extra prefix) and the process should be run under an instance of systemd. I understand that these checks do not cover 100% of cases, but they look good enough for most of them.

Unfortunately older systemd versions (for example the Ubuntu 16.04 has systemd 229) has no direct method of determining if the process is run as a unit, since the $INVOCATION_ID envvar was introduced in systemd 232. To work around this limitation, I had to expand the ServiceManager.IsRunningAsService method to cover older versions. It first performs the original check via the InvocationId property, and then, if it's not available, follows up with checking the parent process command using the getppid(2) and access to the /proc/\<pid>/comm file to check if the parent process is, in fact, an instance of systemd, along with doing some extra checks for user units via $MANAGERPID envvar.

[tmds]

for example the Ubuntu 16.04 has systemd 229

Clearly you are using Ubuntu 16.04 :)

You may want to add this to https://github.com/aspnet/Extensions/blob/8c6d69570722ee4cd6583cbb4af2a9c74c8c10dc/src/Hosting/Systemd/src/SystemdHelpers.cs#L20

[onyxmaster]

Clearly you are using Ubuntu 16.04 :)

Yes, we use a mix of 16.04 and 18.04. I think 16.04 is still quite popular and it's a supported .NET Core platform, so while I am disappointed that 16.04 has such old systemd (for example it lacks most of the interesting sandboxing and system call isolation features), I still actually like it.

You may want to add this to https://github.com/aspnet/Extensions/blob/8c6d69570722ee4cd6583cbb4af2a9c74c8c10dc/src/Hosting/Systemd/src/SystemdHelpers.cs#L20

Thanks for pointing this out, yes, this looks like I need to do yet another stab at .NET Core systemd handling =)

[tmds]

Thanks @onyxmaster! Please contribute this to ASP.NET Core too, and CC me on the PR.

[tmds]

@onyxmaster these changes are part of the 0.7.0 version which I've just uploaded to nuget.org.