<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Gaudenz,<br>
<br>
thank you for your comments. As I tried to explain first, I wanted
to make the smallest possible step that could possibly work
because, from what I understood, once we get in the freeze phase,
users can take the current state as a feature (ie, on the
python-django-pyscss package, Thomas had to selectively choose
commits from the upstream's fix-only branch).<br>
<br>
On 12/01/2014 01:48 AM, Gaudenz Steinlin wrote:<br>
</div>
<blockquote cite="mid:87lhmslp74.fsf@meteor.durcheinandertal.bofh"
type="cite">
I still don't like the idea of using the sysv init script here.
I'd
rather simplify the init script to the point where this is no
longer
needed</blockquote>
<br>
I agree, and I tried to get as close to this as possible. However,
the following feature really doesn't in the systemd's spirit IMHO:<br>
<br>
[ "x$USE_SYSLOG" = "xyes" ] && DAEMON_ARGS="$DAEMON_ARGS
--use-syslog"<br>
[ "x$USE_LOGFILE" != "xno" ] && DAEMON_ARGS="$DAEMON_ARGS
--log-file=$LOGFILE"<br>
<br>
I think a next step will be to get rid of this as it duplicates the
configuration files anyway.<br>
<br>
<blockquote cite="mid:87lhmslp74.fsf@meteor.durcheinandertal.bofh"
type="cite"> and we can just have the following in our unit file:
EnvironmentFile=/etc/default/openstack
/etc/default/${PROJECT_NAME}
And then use the proper variables in the ExecStart setting.
</blockquote>
<br>
In the same way, we should get rid of these environment files. See
the note here
<a class="moz-txt-link-freetext" href="https://wiki.debian.org/systemd/Packaging#overriding_options_and_.2Fetc.2Fdefault_handling">https://wiki.debian.org/systemd/Packaging#overriding_options_and_.2Fetc.2Fdefault_handling</a>:
"Note that it is preferable to configure options using native
systemd mechanisms for new packages". I definitely agree with this
statement but even if I wouldn't, it the Debian project's
recommendation.<br>
<br>
<blockquote cite="mid:87lhmslp74.fsf@meteor.durcheinandertal.bofh"
type="cite">
<blockquote type="cite">
<pre wrap="">1. don't auto-create the /var/*/${PROJECT_NAME} folder if not root, as
it will fail anyway.
</pre>
</blockquote>
<pre wrap="">
Most of these should not be created by the init script anyway. Creating
/var/lib/X and /var/log/X there seems like a bug to me. These should be
part of the package. That's how it's done in all other packages I know.</pre>
</blockquote>
<br>
I agree but I think we can't remove this feature in the freeze
phase. In fact, I think that a real systemd approach wouldn't use a
specific log dir anyway, and just let the software use stdout. You
then have your log managed by journald, with all the wonders like
consistent timestamping and filtering by many criterions. Since
OpenStack has a microservice approach, the log would be naturally
filtered: I'm not aware of any requirement for, for instance, an
access vs error log like with Apache HTTPd or the same kind log
multiplexing (I can think of ISC bind too).<br>
<br>
<blockquote cite="mid:87lhmslp74.fsf@meteor.durcheinandertal.bofh"
type="cite">
<pre wrap="">That's an improvement over the current state. But how do you ensure that
the daemon is started in the foreground?</pre>
</blockquote>
<br>
I tried to get as close as possible to a unit file consisting of
this:<br>
<br>
<tt>[Service]</tt><tt><br>
</tt><tt>User=${SYSTEM_USER}</tt><tt><br>
</tt><tt>Group=${SYSTEM_GROUP}</tt><tt><br>
</tt><tt>WorkingDirectory=/var/lib/${PROJECT_NAME}</tt><tt><br>
</tt><tt>ExecStart=${DAEMON}
--config-file=/etc/${PROJECT_NAME}/${PROJECT_NAME}.conf</tt><tt><br>
</tt><tt>Restart=on-failure</tt><br>
<br>
while retaining still running the daemon with the options users may
expect from the sysv init script. Since start-stop-daemon is used
with the "--background" option and uses a PID file, I know the
program runs in foreground as otherwise stopping would fail, kill a
non-existant PID. So, the do_systemd_start simply does this:<br>
<br>
do_systemd_start() {<br>
exec $DAEMON $DAEMON_ARGS<br>
}<br>
<br>
which replaces the shell process with the daemon one. In the context
of systemd with a service type of "simple", it is strictly
equivalent to<br>
<br>
start-stop-daemon [...] --background [...] --startas $DAEMON
$DAEMON_ARGS<br>
<br>
There's another improvement to do: at least keystone supports
systemd's notification system. Which means we could use a
Type=notify if we did adapt the default configuration file to
include an "onready" configuration:
<a class="moz-txt-link-freetext" href="http://docs.openstack.org/icehouse/config-reference/content/section_keystone.conf.html">http://docs.openstack.org/icehouse/config-reference/content/section_keystone.conf.html</a><br>
<br>
<div class="line number58 index57 alt1"> </div>
<div class="line number59 index58 alt2"><code class="bash comments">#
onready allows you to send a notification when the process</code></div>
<div class="line number60 index59 alt1"><code class="bash comments">#
is ready to serve For example, to have it notify using</code></div>
<div class="line number61 index60 alt2"><code class="bash comments">#
systemd, one could set shell command: "onready = systemd-</code></div>
<div class="line number62 index61 alt1"><code class="bash comments">#
notify --ready" or a module with notify() method: "onready =</code></div>
<div class="line number63 index62 alt2"><code class="bash comments">#
keystone.common.systemd".</code><br>
</div>
<br>
There are also the security improvements you suggested (very
interesting link by the way).<br>
<br>
<blockquote cite="mid:87lhmslp74.fsf@meteor.durcheinandertal.bofh"
type="cite">
<pre wrap="">
The please remove it from the init script alltogether. It's also not
needed when under sysv then.</pre>
</blockquote>
<br>
/var/run is required for the classic sysv system. /var/lib could be
removed from here but it wouldn't be strictly addressing the current
bug, as it is only an issue linked to running the sysv init script
with the service user instead of root.<br>
<br>
<blockquote cite="mid:87lhmslp74.fsf@meteor.durcheinandertal.bofh"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">3. /var/lock/${PROJECT_NAME}, AFAIK, is not needed when using systemd;
</pre>
</blockquote>
<pre wrap="">
What was it used for? Seems strange that there is a difference between
sysv and systemd here.</pre>
</blockquote>
<br>
I think this is only needed by start-stop-daemon to avoid launching
multiple instances, but I may be wrong.<br>
<br>
<blockquote cite="mid:87lhmslp74.fsf@meteor.durcheinandertal.bofh"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">4. /var/log/${PROJECT_NAME} is the only one that is both required and
can be considered volatile.
</pre>
</blockquote>
<pre wrap="">
No this should definitely not be considered volatile. It's ok to delete
the logfiles inside, but no one can expect the daemon to still work if
he just removes this directory completely. For all other packages I know
if this is part of the package and not created on the fly.</pre>
</blockquote>
<br>
While I tend to agree, I think that since it was automatically
recreated, some people now use this as a feature.<br>
<br>
<blockquote cite="mid:87lhmslp74.fsf@meteor.durcheinandertal.bofh"
type="cite">
<pre wrap="">
I would really prefer to have a full systemd unit file that does not
depend on the sysv script at all.</pre>
</blockquote>
<br>
We agree on this goal :-)<br>
<br>
<blockquote cite="mid:87lhmslp74.fsf@meteor.durcheinandertal.bofh"
type="cite">
<pre wrap="">It's fine and probably a good idea to use the files in /etc/default/.
</pre>
</blockquote>
<br>
I not sure its a good idea, as I don't think it makes sense when you
can just throw 2 lines in a /etc/systemd/system unit file to
override the ExecStart line.<br>
</body>
</html>