<div dir="ltr"><div dir="ltr">On Wed, Jul 1, 2020 at 3:03 AM Ian Pilcher <<a href="mailto:arequipeno@gmail.com">arequipeno@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/30/20 4:18 AM, Lennart Poettering wrote:<br>
> <br>
> Maybe it double forks or forks a child off (callout script?) that<br>
> double forks somewhere?<br>
> <br>
> I don't know your software, it's probably best to ping the authors of<br>
> it about this, they should know what their software does.<br>
<br>
LOL!  I am the author.<br>
<br>
So I think I've figured out why I was getting the SELinux message.  The<br>
proximate cause was that I hadn't yet discovered the proper SELinux<br>
policy macro to use when creating the type for the helper application,<br>
so I was building the policy for the helper "from scratch" with low-<br>
level rules.  Now that the policy uses the domain_type() macro, I no<br>
longer get the message.<br>
<br>
As to what was causing the helper to send SIGCHLD to systemd ... I'm not<br>
100% sure that it ever tried to do so.  I have a feeling, however, that<br>
it has something to do with systemd's GuessMainPID feature.  I saw a<br>
couple seemingly random denials (possibly when I had dontaudit rules<br>
disabled) about systemd trying to access the helper application's /proc<br>
directory (which didn't work, because I hadn't used the proper macro).<br>
I don't presume to know the details of how the feature works, but it<br>
makes sense that it might occasionally incorrectly guess that the<br>
helper application is the daemon's main process (particularly when the<br>
daemon first starts, which is when I reliably saw multiple denials).<br>
<br>
If systemd somehow reparents the child process in that circumstance, it<br>
might explain why the SIGCHLD would be sent to systemd, rather than its<br>
parent daemon.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Looks like fixing this program to work properly with Type=simple just<br>
moved up my to-do list.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.)</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>