Hi Gaudenz,
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).
On 12/01/2014 01:48 AM, Gaudenz Steinlin wrote:
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
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:
[ "x$USE_SYSLOG" = "xyes" ] && DAEMON_ARGS="$DAEMON_ARGS --use-syslog"
[ "x$USE_LOGFILE" != "xno" ] && DAEMON_ARGS="$DAEMON_ARGS
--log-file=$LOGFILE"
I think a next step will be to get rid of this as it duplicates the
configuration files anyway.
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.
In the same way, we should get rid of these environment files. See the
note here
https://wiki.debian.org/systemd/Packaging#overriding_options_and_.2Fetc.2Fdefault_handling:
"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.
1. don't auto-create the /var/*/${PROJECT_NAME} folder if not root, as
it will fail anyway.
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.
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).
That's an improvement over the current state. But how do you ensure that
the daemon is started in the foreground?
I tried to get as close as possible to a unit file consisting of this:
[Service]
User=${SYSTEM_USER}
Group=${SYSTEM_GROUP}
WorkingDirectory=/var/lib/${PROJECT_NAME}
ExecStart=${DAEMON} --config-file=/etc/${PROJECT_NAME}/${PROJECT_NAME}.conf
Restart=on-failure
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:
do_systemd_start() {
exec $DAEMON $DAEMON_ARGS
}
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
start-stop-daemon [...] --background [...] --startas $DAEMON $DAEMON_ARGS
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:
http://docs.openstack.org/icehouse/config-reference/content/section_keystone.conf.html
|# onready allows you to send a notification when the process|
|# is ready to serve For example, to have it notify using|
|# systemd, one could set shell command: "onready = systemd-|
|# notify --ready" or a module with notify() method: "onready =|
|# keystone.common.systemd".|
There are also the security improvements you suggested (very interesting
link by the way).
The please remove it from the init script alltogether. It's also not
needed when under sysv then.
/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.
3. /var/lock/${PROJECT_NAME}, AFAIK, is not needed when using systemd;
What was it used for? Seems strange that there is a difference between
sysv and systemd here.
I think this is only needed by start-stop-daemon to avoid launching
multiple instances, but I may be wrong.
4. /var/log/${PROJECT_NAME} is the only one that is both required and
can be considered volatile.
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.
While I tend to agree, I think that since it was automatically
recreated, some people now use this as a feature.
I would really prefer to have a full systemd unit file that does not
depend on the sysv script at all.
We agree on this goal :-)
It's fine and probably a good idea to use the files in /etc/default/.
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.
