Subject: | |
From: | |
Reply To: | |
Date: | Tue, 11 Feb 2014 07:50:20 -0500 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
On Mon, Feb 10, 2014 at 5:52 PM, David Sommerseth
<[log in to unmask]> wrote:
> On 10/02/14 23:02, Tom H wrote:
>>
>> To see a "complex" systemd service file, take a look at a Fedora 20
>> nfs-utils; nfsd is started by three lines:
>>
>> ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-server.preconfig
>> ExecStartPre=/usr/sbin/exportfs -r
>> ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS $RPCNFSDCOUNT
>>
>> I would've used just one ExecStart calling
>> "/usr/lib/nfs-utils/scripts/nfs-server.script" but the maintainer
>> clearly disagrees. :)
>
> Yeah, and I can actually understand a little bit why. Because systemd
> can track the services it has started quite carefully, even after they
> have been started. And can take actions if they die. By starting those
> three from a single script, it would only be able to track that script
> and not all those "features" the script starts.
>
> Another thing is that logging can be somewhat simpler too, and you are
> always guaranteed that logging goes via systemd, even things which goes
> to stdout (and stderr? I don't recall now). A script can easily do odd
> tweaks there too.
>
> So by doing as much as possible in the systemd unit file, it gets less
> convoluted and a bit easier to follow what should happen if you need to
> debug.
Thanks. I hadn't thought of the service supervision aspect. So the
f-ugliness is necessary. :(
|
|
|