Bug#770706: [PKG-Openstack-devel] Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created
On 11/27/2014 04:20 PM, Stig Sandbeck Mathisen wrote: Mikaël Cluseau mclus...@isi.nc writes: Do we agree that with systemd the pid-file logic becomes useless, and thus the proper fix would be to get rid of them, or do you it would be better to keep them, meaning the proper logic becomes the one of tmpfiles.d ? As long as the systemd units run the init scripts, which then fork the daemon, and the daemon makes a PID file, I think PIDFile= should be defined in the systemd unit. Which isn't the case currently, with the latest upload of openstack-pkg-tools = 20 and the latest Keystone that I just uploaded to Sid. Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770706: [PKG-Openstack-devel] Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created
On 12/04/2014 05:42 PM, Gaudenz Steinlin wrote: with the same global section in /usr/share/keystone/keystone-systemd.conf. One can then use /etc/openstack.conf to switch back to syslog or stdout or stderr or whatever she wants globally. That looks like a good solution to me to get rid of the /etc/default files without loosing any functionality. This would avoid duplicating configuration settings in configuration files and /etc/default files. Looks like the best solution to me, but ovviously post jessie. Gaudenz I not sure this is a good solution. The only correct way is to configure it on the command line, with the init system, as we need a per-daemon configuration to keep previous functionality. I'm not even sure that with a non-existent /etc/default/openstack.conf, the daemons would all continue to run without complaining. I very much prefer the current state of things with (shell) configuration files in /etc/default, and I don't see any valid reason why we would stop using that. Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770706: [PKG-Openstack-devel] Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created
Hi Mikael
Thanks for still working on this. I think we are getting closer to a
workable solution.
Mikaël Cluseau mclus...@isi.nc writes:
Hi,
On 12/02/2014 01:52 AM, Gaudenz Steinlin wrote:
So only new changes which fix (RC) bugs are allowed and the changes
should be as minimal as possible to fix the bug.
Since I already posted patches for a minimal set of code changes with a
minimal set of feature changes, I can now move on more radical changes.
My policy is now to follow your comments as long as Thomas doesn't
disagree (including this policy itself ;-)). That's why I've gone
farther in my last reply.
Did you test the patches with the minimal set of changes. I think we
need strong arguments that they are working if we want to propose them
to the Release Team for jessie. I currently don't have a good setup to
test such patches.
I wanted to comment on this already in my first reply but forgot.
What's the advantage of comparing with x prepended here?
I didn't change what existed here. AFAIK, it's a pratice to help have
portable shell scripts.
After thinking about this a bit more, it's only usefull in case the
variable content starts with a - to avoid it being interpreted as a
test flag. Eg. USE_SYSLOG=-f would cause an error without this
construct. The empty variable case is already dealt with the quoting.
So it's probably usefull to keep it.
I don't agree at all here. It's *not* a duplicate. With a
configuration file, you can choose, globally, for a given service,
where to log. You cannot select which daemon. [...] So we really need
this as a feature to make it easy to configure for each service, and
the configuration files just wont do it.
I don't care very much about this. I can see Thomas point [...]
The variables are designed in a way which is a bit hard to support with
systemd. It would be easier if the values in the /etc/default/ files
already contained the command line arguments.
If we want to use these environment files, I can't see a way to keep the
current logic without using a shell. As you say and as is suggested in
https://wiki.debian.org/systemd/Packaging#overriding_options_and_.2Fetc.2Fdefault_handling,
we could switch to an OPTIONS environment variable used in ExecStart.
Supporting USE_SYSLOG and USE_LOGFILE seems hard to do while the OPTIONS
solution improves the feature by allowing to specify globally any
globally recognized daemon parameters. Thus, I think it's a reasonable
choice that is easy to support in both init systems. As there's a
consensus on keeping the same interface for the sysv-rc and systemd, we
should change the init script accordingly.
Yes supporting the yes/no variables is probably not possible directly in
systemd. If we really want to keep them, then we need a small script to
compile the needed command line arguments from them.
My proposal is the following:
EnvironmentFile=-/etc/default/openstack
EnvironmentFile=-/etc/default/${NAME}
ExecStart=${DAEMON}--config-file=/etc/${PROJECT_NAME}/${PROJECT_NAME}.conf
\${OPTIONS}
We could even use the following environment files when $PROJECT_NAME !=
$NAME:
EnvironmentFile=-/etc/default/openstack
EnvironmentFile=-/etc/default/${PROJECT_NAME}
EnvironmentFile=-/etc/default/${NAME}
I like this proposal. It would also simplify the sysv init script and
it's more flexible than the current approach at the same time. I prefer
this to the current set of yes/no variables. I'm not sure if an
automatic migration is necessary or if a NEWS.Debian entry is enough. I
would probably go for the latter as an automatic migration might be hard
to get right.
This change is certainly post jessie IMO. I don't think we should change
/etc/default settings for jessie at this stage. I don't think anyone
disputes that, just to be clear.
Thomas what do you think about it?
I don't yet fully understand how the templates in openstack-pkg-tools
work. How are service specific values filled in?
Every package has a debian/${DAEMON}.init.in with the variables defined.
For instance for keystone:
[...]
DESC=OpenStack Identity service
PROJECT_NAME=keystone
NAME=keystone
DAEMON=/usr/bin/keystone-all
OK, so PROJECT_NAME, NAME and DAEMON are all set on a per service basis
in the individual packages.
I agree that we should let the operator choose how he want's to do
logging. I don't think anyone want's to dispute that. But we need a
default configuration. Certainly we don't want debug logging by
default at all. Anyway the discussion was about creating /var/log and
/var/lib from the sysv init script. This is wrong in all cases
independently how logging is done. This just belongs to the package.
I agree that someone switching where the log file are should create the
log directories accordingly. As a consequence, if we default to
/var/log/${PROJECT_NAME}, and if every other package is creating these
at install time, we probably should do the same
Bug#770706: [PKG-Openstack-devel] Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created
Hi all,
I tried to minimize the changes to get close to a unit file in the
systemd spirit, while still using on the init-script to keep same
features as before. The patch below reflect the following actions:
1. don't auto-create the /var/*/${PROJECT_NAME} folder if not root, as
it will fail anyway.
2. add a do_systemd_start function to implement the systemd-start
argument that will exec' the daemon with the previously computed args.
3. since then systemd will manage the daemon, the systemd-stop argument
can be removed.
4. since the script doesn't create the necessary folders anymore, create
what's required using the systemd unit file.
The point 4 is where I did the most invasive choices; I assumed that
1. /var/run/${PROJECT_NAME} is not needed since PID file is not created
anymore (process managed by systemd);
2. /var/lib/${PROJECT_NAME} doesn't have to be created as it is created
when the package is installed;
3. /var/lock/${PROJECT_NAME}, AFAIK, is not needed when using systemd;
4. /var/log/${PROJECT_NAME} is the only one that is both required and
can be considered volatile.
If any of these choices is wrong, it's easy to add the folder in the
ExecStartPre lines of the systemd unit file.
If the systemd-stop argument should still be supported, I think it
should be noop or print a depreciation warning.
As a consequence of these changes, the unit file doesn't need its
RuntimeDirectory and PIDFile directives. Since the daemon is exec'd, the
Type falls back to the default (simple) so it is removed too.
I don't how to do less than that, so here is my minimal patch proposal:
diff --git a/init-template/init-script-template
b/init-template/init-script-template
index 0326b5d..fd20957 100644
--- a/init-template/init-script-template
+++ b/init-template/init-script-template
@@ -36,11 +36,13 @@ fi
# Exit if the package is not installed
[ -x $DAEMON ] || exit 0
-# Create /var/lock/X, /var/run/X, /var/lib/X and /var/log/X
-for i in lock run log lib ; do
-mkdir -p /var/$i/${PROJECT_NAME}
-chown ${SYSTEM_USER} /var/$i/${PROJECT_NAME}
-done
+# If ran as root, create /var/lock/X, /var/run/X, /var/lib/X and
/var/log/X as needed
+if [ x$USER = xroot ] ; then
+for i in lock run log lib ; do
+mkdir -p /var/$i/${PROJECT_NAME}
+chown ${SYSTEM_USER} /var/$i/${PROJECT_NAME}
+done
+fi
# This defines init_is_upstart which we use later on (+ more...)
. /lib/lsb/init-functions
@@ -65,6 +67,10 @@ do_stop() {
return $RETVAL
}
+do_systemd_start() {
+exec $DAEMON $DAEMON_ARGS
+}
+
case $1 in
start)
init_is_upstart /dev/null 21 exit 1
@@ -88,11 +94,8 @@ status)
status_of_proc $DAEMON $NAME exit 0 || exit $?
;;
systemd-start)
-do_start
+do_systemd_start
;;
-systemd-stop)
-do_stop
-;;
restart|force-reload)
init_is_upstart /dev/null 21 exit 1
log_daemon_msg Restarting $DESC $NAME
@@ -110,7 +113,7 @@ restart|force-reload)
esac
;;
*)
-echo Usage: $SCRIPTNAME
{start|stop|status|restart|force-reload|systemd-start|systemd-stop} 2
+echo Usage: $SCRIPTNAME
{start|stop|status|restart|force-reload|systemd-start} 2
exit 3
;;
esac
diff --git a/init-template/pkgos-gen-systemd-unit
b/init-template/pkgos-gen-systemd-unit
index b97e2a9..09cf3e5 100755
--- a/init-template/pkgos-gen-systemd-unit
+++ b/init-template/pkgos-gen-systemd-unit
@@ -33,12 +33,11 @@ $AFTER
[Service]
User=${SYSTEM_USER}
Group=${SYSTEM_GROUP}
+PermissionsStartOnly=true
+ExecStartPre=/bin/mkdir -p /var/log/${PROJECT_NAME}
+ExecStartPre=/bin/chown ${SYSTEM_USER}:${SYSTEM_GROUP}
/var/log/${PROJECT_NAME}
ExecStart=${SCRIPTNAME} systemd-start
-ExecStop=${SCRIPTNAME} systemd-stop
-RuntimeDirectory=${PROJECT_NAME}
-PIDFile=/var/run/${PROJECT_NAME}/${NAME}.pid
Restart=on-failure
-Type=forking
[Install]
WantedBy=multi-user.target
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770706: [PKG-Openstack-devel] Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created
Mikaël Cluseau mclus...@isi.nc writes: Do we agree that with systemd the pid-file logic becomes useless, and thus the proper fix would be to get rid of them, or do you it would be better to keep them, meaning the proper logic becomes the one of tmpfiles.d ? As long as the systemd units run the init scripts, which then fork the daemon, and the daemon makes a PID file, I think PIDFile= should be defined in the systemd unit. If PIDFile= is not set, systemd will make a guess as to what the main pid is, and it may be wrong. The relevant bits from man systemd.service(5): ,[ GuessMainPID= ] | Takes a boolean value that specifies whether systemd should try to | guess the main PID of a service if it cannot be determined reliably. | This option is ignored unless Type=forking is set and PIDFile= is | unset because for the other types or with an explicitly configured PID | file, the main PID is always known. The guessing algorithm might come | to incorrect conclusions if a daemon consists of more than one | process. If the main PID cannot be determined, failure detection and | automatic restarting of a service will not work reliably. Defaults to | yes. ` ,[ PIDFile= ] | Takes an absolute file name pointing to the PID file of this daemon. | Use of this option is recommended for services where Type= is set to | forking. systemd will read the PID of the main process of the daemon | after start-up of the service. systemd will not write to the file | configured here. ` -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770706: [PKG-Openstack-devel] Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created
Mikaël Cluseau n...@nwrk.info writes: Hi, isn't it a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767711 ? Yes. I suggest a merging of bugs. :) Note: The proposed solution in that bug will not work for services sharing the same runtime directory. The services will delete each others runtime directory and pid files. -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770706: [PKG-Openstack-devel] Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created
On 11/27/2014 09:23 AM, Stig Sandbeck Mathisen wrote: Note: The proposed solution in that bug will not work for services sharing the same runtime directory. The services will delete each others runtime directory and pid files. Do we agree that with systemd the pid-file logic becomes useless, and thus the proper fix would be to get rid of them, or do you it would be better to keep them, meaning the proper logic becomes the one of tmpfiles.d ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770706: [PKG-Openstack-devel] Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created
On 11/27/2014 06:31 AM, Mikaël Cluseau wrote: On 11/27/2014 09:23 AM, Stig Sandbeck Mathisen wrote: Note: The proposed solution in that bug will not work for services sharing the same runtime directory. The services will delete each others runtime directory and pid files. Do we agree that with systemd the pid-file logic becomes useless Unfortunately, no, I don't agree. Not with the (poor) way we've designed things in openstack-pkg-tools, which still uses start-stop-daemon. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770706: [PKG-Openstack-devel] Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created
Hi, isn't it a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767711 ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770706: [PKG-Openstack-devel] Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created
On 11/24/2014 01:52 AM, Gaudenz Steinlin wrote: Why do you set PIDFile at all? IMO pidfiles are unnecessary when the daemons managed by systemd run in the foreground and thus there is no need for a pidfile at all. The point is, the way things are designed currently, we don't use foreground at all right now, we continue to use start-stop-daemon and execute the init.d startup script, even when using systemd. This is a bad design that would need improvement, and I would welcome a better implementation within openstack-pkg-tools. I would very much like to see some patches to use foreground (the way it's done in Fedora?), but it should support all properties and implementation of what's done in the init scripts. On 11/24/2014 04:54 AM, Mikaël Cluseau wrote: Hi, isn't it a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767711 ? Yes it is. And that's a general issue with all OpenStack packages in Sid/Jessie right now. We need to fix all of this before the 5th of December deadline. Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
