[systemd-devel] Support for pre-restart check

"Jóhann B. Guðmundsson" johannbg at gmail.com
Wed Jul 30 22:03:48 PDT 2014


On 07/31/2014 12:16 AM, Colin Guthrie wrote:
> I think the use case is pretty clear tho'. Config (or general machine
> state) has transitioned from working to broken in the time since the
> service was started and while it's really not a nice situation to find
> yourself in (relying on a running service not crashng!), this at least
> helps avoid nasty consequences for the most part while you work to fix
> things.

The use case administrator want, is fixing their own lazyness and 
incompetence not having to run the configuration syntax checker by hand 
after they made changes to the configuration for one of those handful of 
daemon/service that actually come with those.

But let's continue on this path once that is implemented they want to be 
notified one way or another why the service failed to be restarted as in 
the actual failed line of the configuration mistake they made so they 
can go and fix it ( and apachctl -t purpose is... ) but that cannot be 
implemented in the status output because. remember they where to lazy to 
run the configuration syntax checker by hand after the change they made 
so they are to lazy to run systemctl status foo so you do realize the 
underlying problem for this cannot be solved right?

People tried in the past doing so by writing massive initscript that 
never worked...

Now that broken machine state is not limited to configuration changes 
since it could also happen due to an bad update or incompatable update ( 
configuration file syntax changes between releases, apache 2.2 vs 2.4 
for example ) so the only way you can try to solve this is by 
introducing a fake restart of the service which cannot be manually 
defined what is but has to be built in with the know of only turning it 
on or off for type units which covers *something* has changed can the 
service be restarted *safely* afterwards, if it does restart the service.

Bottom line if the intent is for systemd to solve the use case you 
stated the solution for this need to be a permanent fix that covers all 
service/daemons not yet another line that leads to administrators define 
another command to take care of that...

JBG


More information about the systemd-devel mailing list