On Sun, 15.05.11 15:55, "Jóhann B. Guðmundsson" (johannbg(a)gmail.com) wrote:
On 05/15/2011 01:59 PM, Lennart Poettering wrote:
> On Thu, 12.05.11 17:04, "Jóhann B. Guðmundsson" (johannbg(a)gmail.com)
wrote:
>
>> You can run ExecStartPre= before starting a service for syntax checking
>> before starting the service like we do for ..
>>
>> ExecStartPre=/usr/sbin/radiusd -C
>> ExecStartPre=/usr/sbin/named-checkconf /etc/named.conf
>> ExecStartPre=/usr/sbin/cupsd -t
> Humm, I really wonder what the benefit of placing these lines here
> is. What does it buy you?
>
> A sane daemon should do a syntax check anyway when starting (and exit if
> it fails), so why do you do another one before? Unless there's a really
> good reason for it this just complicates things, makes things slower,
> and duplicates everything.
For example if you are doing autogenerated updates on config files you
might want to test the config before restarting/reloading the daemon
which is commonly done in enterprise environments running Freeradius and
Bind atleast those environments I'm familiar with ( cups not so much
)...
Well, but ExecStartPre= doesn't help you with this. As it is run only
after the service is already stopped.
It has been suggested that we add ExecRestartPre=, i.e. something we run
before stopping a service for a restart. It has been on the TODO list
for a while, but is currently not available. ExecStartPre= doesn't
appear useful for this stuff at all to me.
Also the previous behaviour when starting a service used to throw out
which config file and which line the syntac error occoured to the
console however that's no longer the case see
https://bugzilla.redhat.com/show_bug.cgi?id=684152.
In F16 it is our plan to make all service STDOUT/STDERR to go to syslog
by default. As soon as we have that and also can relate syslog output to
systemd services we can make this kind of output more accessible.
As I have mentioned to you previously systemd lacks certain
administrative features ( yet ) like fine grained failour handling (
like ExecStartPreFail= etc. ) and more and it comes as a no surprice
since you seem to have a limited sysadmin perspective/experience on
things ( after all you are a developer not sysadmin ) as your blog post
indicates which are targeted more at the above average end user running
something @ home than real sysadmins in real enterprise environments
from my pov.
Sorry, I still haven't found the time to reply to your long mail about
this. It's not forgotten. ;-) From a quick browse through it I think
this is mostly a misunderstanding however, and you can already do what
you want to do with the current code.
Lennart
--
Lennart Poettering - Red Hat, Inc.