[systemd-devel] Child of daemon sending SIGCHLD to systemd

[Ian Pilcher]

On 7/1/20 3:47 AM, Mantas Mikulėnas wrote:
> systemd doesn't explicitly reparent processes; the kernel just always 
> reparents processes to pid 1 when the previous parent no longer exists. 
> Overall, pid 1 is a legitimate recipient of SIGCHLD regardless of which 
> init system is being used.

In this case, the parent definitely still exists.  As I mentioned in my
previous note, just because I saw an SELinux AVC about the helper
application sending SIGCHLD to and init_t process, that doesn't make it
100% certain that the signal was actually sent to systemd; it's possible
that some other, related action is also included in the SELinux
"sigchld" permission, possibly something that would be triggered if
systemd's heuristics decided that the helper process was actually the
"main PID" of the service.

> With Type=forking, systemd is able to read from whatever PIDFile= your 
> daemon creates, if it creates any. This would also remove the need for 
> GuessMainPID.

The daemon doesn't create  PID file, and I'm certainly not going to add
that functionality now.  :-)

> The ideal choice would be Type=notify, however, since it adds readiness 
> notification on top of Type=simple. (With simple, other daemons wouldn't 
> be able to properly order After=freecusd, but with Type=notify you only 
> need to call sd_notify("READY=1") at the proper moment.)

Good thought.  This daemon doesn't provide services to anything else on
the NAS.  It just monitors things, displays the status on the front-
panel LCD display and LEDs, and controls the fan speed.  That being the
case, I don't think that there's any real benefit to it in this case.

If that ever changes, though ...

-- 
========================================================================
                  In Soviet Russia, Google searches you!
========================================================================