Discussion:
Idea: adding WantsFileBefore= and WantsFileAfter=?
(too old to reply)
Ryan Gonzalez
2018-03-20 21:08:33 UTC
Permalink
Raw Message
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.

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.

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.

Thoughts?
--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/
Lennart Poettering
2018-03-20 21:22:40 UTC
Permalink
Raw Message
Post by Ryan Gonzalez
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.
Post by Ryan Gonzalez
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.
Post by Ryan Gonzalez
Here's my idea: what if there were WantsFileBefore= and WantsFileAfter=
[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
Ryan Gonzalez
2018-03-24 01:35:32 UTC
Permalink
Raw Message
I know everyone here is super busy, but I just wanted to bump this a
sec before letting it die to make sure it didn't just get lost or
something. (If someone agrees that it should be a feature, I'd happily
try to work on it.)
Post by Ryan Gonzalez
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.
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.
Here's my idea: what if there were WantsFileBefore= and
[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.
Thoughts?
--
Ryan (ラむアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/
--
Ryan (ラむアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/
Colin Guthrie
2018-03-27 09:11:45 UTC
Permalink
Raw Message
Perhaps you missed Lennart's reply?

I have to say it doesn't sound like the right place to fix things.
Really the daemon needs to be fixed.

What you suggest sounds quite racy generally (at least the
WantsFileBefore= bit anyway) and really is just to paper over a badly
written daemon that also breaks (at least in theory) on SysV. I'd say
effort would be better spent making the daemon work.

Failing that (i.e. if the daemon code is not available), I'd just write
a very simple wrapper around your binary that implements the appropriate
waiting around the execution and keep the hack localised to this daemon
(or just stick with your ExecPreStart/PostStart and your "wait-for-file"
script solution). Probably not a general purpose approach that should be
encouraged :-)

Col
I know everyone here is super busy, but I just wanted to bump this a sec
before letting it die to make sure it didn't just get lost or something.
(If someone agrees that it should be a feature, I'd happily try to work
on it.)
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. 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. 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. Thoughts?
--
Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki
Sawano >> everyone else https://refi64.com/
--
Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano
everyone else https://refi64.com/
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
r***@gmail.com
2018-03-27 14:47:46 UTC
Permalink
Raw Message
_______________________________________________
systemd-devel mailing list
systemd-***@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Loading...