Idea: adding WantsFileBefore= and WantsFileAfter=?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Ryan Gonzalez wrote on 24/03/18 01:35:
> 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.)
> 
> On Tue, Mar 20, 2018 at 4:08 PM, 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. 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
> systemd-devel at lists.freedesktop.org
> 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/


[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux