[PKG-Openstack-devel] Bug#770706: Bug#770706: Bug#770706: Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created

[Mikaël Cluseau]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/openstack-devel/attachments/20141201/c9d69ec9/attachment.html>