Hello!
I'm working on passing sd_notify events from systemd-{pull,import} through
sysupdate.
All services that consume sd_notify events (systemd itself, importd,
machined, homed, etc) act as daemons and own a directory in /run. Thus,
they can open a notification socket at, say, /run/SERVICENAME/notify and
set NOTIFY_SOCKET to that. Also, there's no cleanup involved: if the
service goes away the file sticks around until the service is restarted.
sysupdate, however, is the first instance of a worker process forking off
another worker process. Thus, we cannot bind the notify socket to some
stable name. Here are potential approaches I've explored to solve this:
- Simply pass through the NOTIFY_SOCKET environment variable. That's not
suitable because we want to export an overall progress value (smoothly from
0 to 100), but systemd-import is forked off multiple times so we'd instead
export a progress value that bounces around from 0 to 100 and back to 0.
Also progress messages would come from different PIDs for a single
invocation of sysupdate
- Create a temporary file and use that as the socket. Problem: What happens
if systemd-sysupdate crashes and we don't get to clean up that file? Over
time that potentially clutters up /tmp! Is this a concern?
- Use socketpair to open an anonymous socket and pass it into the child.
This one seems ideal on paper but it doesn't actually work. I can modify
sd_notify to just use an open file descriptor instead of tying to open its
own, and that does work except for some reason process credentials aren't
sent over. Also using the socket pair method doesn't work all that well
with CLOEXEC, though maybe we don't want to CLOEXEC (We'd only close the
socket when sd_notify is called with unset_env=true)
- Create an abstract socket, named after the PID of the parent sysupdate.
i.e. @/run/sysupdate/PID/notify. I'm not super familiar with abstract
sockets so I'm not sure of the downsides
Which approach would you suggest?
Best,
Adrian
