On 07/08/2014 01:02 AM, Michael Stapelberg wrote: > 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 :).
I do agree in principle. However, practically, many daemon do need the network to be up to be able to bind correctly. :( Do you know what's the default behavior if you bind on 0.0.0.0? Will the daemon just pick-up whatever new IP is configured after its started? >>>> 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. But this is available in all OpenStack daemons directly, using the command line arguments, which is what I want to use. > 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. Well... no! :) I have to insist. What I want is to be able to use whatever the user configures in /etc/default, just like I'm doing right now already. And this is configured through the command line of each daemons. I know that there's scripting available in systemd units, but I couldn't find out how to make it influence the ExecStart directive. > 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. However, systemd journal have some issues, as much as I have read, and unless things changed. First, it wouldn't do network logging, just like syslog does (am I right here?). And then, it wouldn't handle extreme loads in the order of terabytes per day. So I want to keep things configurable. >> 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. Ok, so it will read stuff in /etc/default/openstack. But then how do I make ExecStart have different startup command depending on the EnvironmentFile? What if EnvironmentFile=/etc/default/openstack doesn't exist (which would be the default case)? Would it still continue to work and start the daemon? Cheers, Thomas Goirand (zigo) _______________________________________________ Pkg-systemd-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
