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

[Mantas Mikulėnas]

On Wed, Jul 1, 2020 at 3:03 AM Ian Pilcher <arequipeno at gmail.com> wrote:

> On 6/30/20 4:18 AM, Lennart Poettering wrote:
> >
> > Maybe it double forks or forks a child off (callout script?) that
> > double forks somewhere?
> >
> > I don't know your software, it's probably best to ping the authors of
> > it about this, they should know what their software does.
>
> LOL!  I am the author.
>
> So I think I've figured out why I was getting the SELinux message.  The
> proximate cause was that I hadn't yet discovered the proper SELinux
> policy macro to use when creating the type for the helper application,
> so I was building the policy for the helper "from scratch" with low-
> level rules.  Now that the policy uses the domain_type() macro, I no
> longer get the message.
>
> As to what was causing the helper to send SIGCHLD to systemd ... I'm not
> 100% sure that it ever tried to do so.  I have a feeling, however, that
> it has something to do with systemd's GuessMainPID feature.  I saw a
> couple seemingly random denials (possibly when I had dontaudit rules
> disabled) about systemd trying to access the helper application's /proc
> directory (which didn't work, because I hadn't used the proper macro).
> I don't presume to know the details of how the feature works, but it
> makes sense that it might occasionally incorrectly guess that the
> helper application is the daemon's main process (particularly when the
> daemon first starts, which is when I reliably saw multiple denials).
>
> If systemd somehow reparents the child process in that circumstance, it
> might explain why the SIGCHLD would be sent to systemd, rather than its
> parent daemon.
>

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.


>
> Looks like fixing this program to work properly with Type=simple just
> moved up my to-do list.
>

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 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.)

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200701/ebf50967/attachment.htm>