Adding systemd unit files in OpenStack packages

Michael Stapelberg stapelberg at debian.org
Mon Jul 7 18:02:55 BST 2014


Hi Thomas,

Thomas Goirand <zigo at debian.org> writes:
> Well, network should be up, so that the IP is configured, and the daemon
> can bind on it. But probably this part is already handled by the fact
> I'm writing WantedBy=multi-user.target?
No. You should explicitly add “After=network.target”. This is roughly
equivalent to what $network in sysvinit scripts meant. Do note that
systemd in general expects programs to behave reasonably when being
faced with changing network interfaces, i.e. network interfaces can go
down or come up at any point in time, and the configured IP addresses
can also change.

This is not behavior that was introduced by systemd, but rather an
observation of the status quo in today’s world (think of mobile devices
for example). Hence, systemd does not pretend to provide a point at
which “the network is up”, which is a broken concept these days :).

>
>>> Then another example. With nova-compute, I have the following:
>>>
>>> [ -r /etc/default/openstack ] && . /etc/default/openstack
>>> [ -r /etc/default/$NAME ] && . /etc/default/$NAME
>>>
>>> [ "x$USE_SYSLOG" = "xyes" ] && DAEMON_ARGS="$DAEMON_ARGS --use-syslog"
>>> [ "x$USE_LOGFILE" != "xno" ] && DAEMON_ARGS="$DAEMON_ARGS \
>>> 	--log-file /var/log/nova/$NAME.log"
>>>
>>> The idea is that, by default, nova-compute only logs to a file. That is,
>>> unless someone configures /etc/default/nova-compute. It is also possible
>>> configure it globally in /etc/default/openstack (with the same
>>> directives). How do I do this in a systemd unit file?
>> 
>> I think they probably should log to the journal by default.
>
> I don't think so. File logging is what everybody does by default in
> OpenStack, so I don't want to change the default behavior, only provide
> another (optional) facility, easily configured.
See StandardOutput in systemd.exec(5) for the logging facilities that
systemd provides. Note that logging to a file is absent from these
facilities. Instead, as ansgar suggested, you should log to the
journal. In case logging to a file is expected by OpenStack people, how
about shipping a syslog config fragment that will make rsyslog write the
messages generated by OpenStack to a file? That way, you’ll have both.

I do expect the majority of users to look into the journal in a while,
though, as it’s just so much more convenient to use/filter/search than
regular files.

>> If the admin
>> wants to change this, he can override the ExecStart= option to pass
>> different options to the executable.
>> 
>> Just let the daemon write to stdout/stderr and set
>> StandardOutput=journal if it has no built-in support for logging the the
>> journal itself.
>> 
>> systemd can do variable substitution, but logic like "if USE_SYSLOG=yes,
>> then append --use-syslog to startup options" isn't directly supported.
>> It is however considered better style not to rely on these features.
>
> Well, I do not want to change the current behavior, as I know some
> OpenStack on Debian users already have it in production. Having stuff
> configured in a systemd units isn't ideal also because there's no unique
> single place to configure all daemons (eg: /etc/default/openstack), and
> configuring each and every systemd unit by hand wouldn't be nice. So I
> would like to keep current behavior with systemd as well.
The canonical way in systemd to configure things is in the configuration
file of the application itself. If the application does not support
that, the administrator would write a config snippet,
e.g. /etc/systemd/system/apache2.service.d/ulimit.conf that overwrites a
specific part of the service file, e.g.:

  [Service]
  LimitNOFile=4096

Anyway, if you really really insist, you can use
EnvironmentFile=/etc/default/openstack in your service files and use
variables defined therein. Mind you, that’s not an idiomatic service
file then, though, and perhaps people will be surprised/disappointed to
see that openstack is deviating.

-- 
Best regards,
Michael




More information about the Pkg-systemd-maintainers mailing list