systemd-notify: Always pass a valid pid to sd_pid_notify

[dvdhrm]

If the option --pid was used, take the pid from this option, unless take
the parend pid. Using 0 as pid (ucred of systemd-notify) will result 99% of the
time in a failure with this error: "Cannot find unit for notify message of PID"

Shouldn't we use always the ppid, since the MAINPID is something else ?

Signed-off-by: Benjamin Robin dev@benjarobin.fr

[poettering]

Looks OK to me. Let's see if Semaphore agrees too!

[dvdhrm]

This is imported from the ML. I wonder whether we should also set MAINPID correctly?

[dvdhrm]

That is, make parse_argv() set arg_pid = arg_pid ? : getppid();.

[poettering]

Hmm, that's a very good question. But I think it should not do that.

--pid= sets the main PID, and then sends the message on its behalf.

If --pid= is not set, then this would mean, we send the message from our parent, (which is a safer choice, since it's going to be around for longer than our tool), but this should not make it the main pid of the daemon, because we don't know if it is.

Note that --pid also may be invoked without arguments, in which case the main PID is set to getppid(). Thus we cover all three cases already:

1. no argument sets no main PID, and sends on behalf of the PPID
2. --pid without argument sets the PPID as main PID and sends on its behalf
3. --pid= with argument sets the specified PID as main PID and sends on its behalf

The user hence has a nice choice and the main PID is only set if explicitly requested, otherwise we don't do that.

Or in other words: patch looks good to merge, still.