Idea: adding WantsFileBefore= and WantsFileAfter=?

[lennart@xxxxxxxxxxxxxx (Lennart Poettering)]

On Di, 20.03.18 16:08, Ryan Gonzalez (rymg19 at gmail.com) wrote:

> Hello!!
> 
> Recently, I was trying to help out someone on IRC move some sysvinit scripts
> over to systemd units, and there was one interesting issue that came up.
> Many older daemons will create sockets at some unspecified point in their
> startup sequence, with no indication of when this occurs. In this case, it
> was a bit after the pid file, so systemd started running units that required
> this socket ready before it was actually ready.

Well, on both SysV and on systemd the only correct way to race-freely
establishing listening sockets is to do so *before exiting* in the
original process that forks off the main daemon process into the
background. If you service does that correctly on SysV, then systemd
can handle it fine, too, when Type=forking is used. If you service
does not do that, then it is broken on both systemd and SysV, and
should really be fixed.

> Using socket activation here would be great, but again, this is an older
> daemon, and AFAIK socket activation *always* requires a deamon to read the
> socket path over stdin.

Socket activation is great, but not needed, if the service is written
correctly for SysV and Type=forking is used.

> 
> Here's my idea: what if there were WantsFileBefore= and WantsFileAfter=
> options, that could be used like this:
> 
> [Service]
> Type=oneshot
> ExecStart=/usr/bin/my-service
> WantsFileBefore=this-file-should-be-existant-before-running-service
> WantsFileAfter=systemd-should-wait-until-this-file-exists-before-continuing
> 
> In short, WantsFileBefore=file would be roughly equivalent to
> ExecPreStart=wait-for-file file, and WantsFileAfter=file would be roughly
> equivalent to ExecPostStart=wait-for-file file. Of course, now there would
> be no need to useless shell commands.

This appears unnecessary, and wouldn't fix the daemon for SysV either...

Lennart

-- 
Lennart Poettering, Red Hat