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

Re: A few observations about systemd



On Sat, Jul 23, 2011 at 4:47 PM, Stephan Seitz
<stse+debian@fsing.rootsland.net> wrote:
> On Fri, Jul 22, 2011 at 05:09:11PM +0200, Michael Biebl wrote:
>>>
>>> Configuration file for the daemon is /etc/default/rsyslog:
>>
>> The canonical configuration file for the rsyslog daemon is
>> /etc/rsyslog.conf.
>
> Yes, but it doesn’t allow you to change start options of the daemon itself.

Those should be configurable through the configuration file.

>> include that via EnvironmentFile=/etc/foo/bar [1]. If it is avoidable, you
>> shouldn't do that though, as /etc/default files are Debian specific and one
>> aim of systemd is, that unit files are usable cross-distro.
>
> I don’t know if files in /etc/default are Debian specific ones, but
> sometimes you need to change start parameters of the daemon. One example is
> sasldauth. If you have postfix in a chroot environemnt (standard Debian),
> you need to change the parameter for the named socket.

Those should be configurable through the configuration file. If that's
not possible for some random daemon, write a wrapper.

> So you need a configuration file at least for certain daemons to change
> options for the daemon start.
>
>> A lot of those /etc/default files have a ENABLED=YES flags, which are not
>> particularly useful with systemd, as systemd provides proper mechanisms to
>> enable/disable services in a convenient way.
>
> Well, that is fine. I often disable a service by putting a „exit 0” in its
> init script, if I don’t want to always run this service. But why are the
> unit files not configuration files to begin with like init scripts?  In my
> eyes they all belong in /etc.

If you want to configure the init files, feel free to copy them to etc
and edit them there (as has been mentioned in this thread already).
Adding "exit 0" to a init script is not really a good idea (as has
been mentioned in this thread already too).

Let's put it this way. Systemd splits the metadata required to
initialize a service (such as what the daemon provides, what needs to
be done to start it up, what should activate it, i.e., all the stuff
that's stored in declarative init files) from the configuration of the
service (stored in the daemon configuration files). The former is data
and clearly doesn't belong in etc.


Reply to: