Hi Thomas, Thomas Goirand <[email protected]> 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 _______________________________________________ Pkg-systemd-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
