Bug#770706: [PKG-Openstack-devel] Bug#770706: Bug#770706: Bug#770706: Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created
On 12/13/2014 05:29 AM, Thomas Goirand wrote: Let's work on this after the freeze, indeed! Great, I'll help then :-) -- 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: Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created
Hi,
On 12/06/2014 03:14 AM, Gaudenz Steinlin wrote:
I'm not sure if I understand your concerns.
I think it is the difference between
* having one distribution-managed configuration file per daemon (like
in /usr/share/project/daemon.conf) containing the default log
file, meaning 58 configuration files (see the list at the end)
* versus having it computed in the init-script instead
(LOGFILE=/var/log/${PROJECT_NAME}/${NAME}.log)
I'm more inclined to have it explicitly put anyway because 58 files is
not that much, but as a developper too I can understand the problem that
it is a defactorised form. Maybe the best thing to do would be to allow
some templating in OpenStack configurations themselves.
Also note that using a small shell wrapper could be an idea too, as
systemd doesn't go against using shell scripts to launch service: it
simply enables us to avoid running (maybe 1ms?). The shell wrapper could
be generic and take 2 arguments : the project name and the daemon name.
This would allow us to avoid init-script when sysv init is not in use,
and using only one script means the system doesn't have to load many
files (it will be cached when the first openstack daemon is started).
List of configuration files required to manage the one logfile per
daemon logic, exclude /usr/share prefix:
ceilometer/ceilometer-agent-central.conf
ceilometer/ceilometer-agent-compute.conf
ceilometer/ceilometer-agent-notification.conf
ceilometer/ceilometer-alarm-evaluator.conf
ceilometer/ceilometer-alarm-notifier.conf
ceilometer/ceilometer-api.conf
ceilometer/ceilometer-collector.conf
cinder/cinder-api.conf
cinder/cinder-backup.conf
cinder/cinder-scheduler.conf
cinder/cinder-volume.conf
designate/designate-agent.conf
designate/designate-api.conf
designate/designate-central.conf
designate/designate-sink.conf
fuel-astute/astute.conf
fuel-nailgun/nailgun-api.conf
fuel-nailgun/nailgun-assassin.conf
fuel-nailgun/nailgun-reciever.conf
glance/glance-api.conf
glance/glance-registry.conf
heat/heat-api-cfn.conf
heat/heat-api-cloudwatch.conf
heat/heat-api.conf
heat/heat-engine.conf
ironic/ironic-api.conf
ironic/ironic-conductor.conf
keystone/keystone.conf*
murano-agent/murano-agent.conf
murano/murano-api.conf
murano/murano-engine.conf
neutron/neutron-dhcp-agent.conf
neutron/neutron-l3-agent.conf
neutron/neutron-lbaas-agent.conf
neutron/neutron-metadata-agent.conf
neutron/neutron-metering-agent.conf
neutron/neutron-plugin-linuxbridge-agent.conf
neutron/neutron-plugin-openvswitch-agent.conf
neutron/neutron-server.conf
neutron/neutron-vpn-agent.conf
nova/nova-api.conf
nova/nova-baremetal.conf
nova/nova-cells.conf
nova/nova-cert.conf
nova/nova-compute.conf
nova/nova-conductor.conf
nova/nova-consoleauth.conf
nova/nova-console.conf
nova/nova-consoleproxy.nova-novncproxy.conf
nova/nova-consoleproxy.nova-serialproxy.conf
nova/nova-consoleproxy.nova-spicehtml5proxy.conf
nova/nova-consoleproxy.nova-xenvncproxy.conf
nova/nova-network.conf
nova/nova-scheduler.conf
sahara/sahara.conf
tuskar/tuskar-api.conf
tuskar/tuskar-manager.conf
zuul/zuul-server.conf
Bug#770706: [PKG-Openstack-devel] Bug#770706: Bug#770706: Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created
On 12/05/2014 01:01 AM, Thomas Goirand wrote: Then later we can test that... though the build is for Wheezy, so I'm not sure if that's so relevant. Is systemd working well in Wheezy? I've been using systemd in wheezy for over a year now. It's working well, especially if you use wheezy-backports to get systemd 200 instead of 44 that ships with plain wheezy. So, I think a test with this version is very close to the state we will have in jessie. -- 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: Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created
On 12/05/2014 06:04 AM, Gaudenz Steinlin wrote: One thing I noticed is that all services are disabled by default even though they were configured through debconf and should be ready to use. Is this intentional as an off by default behavior or is this a bug. How is this handled with sysvinit? For what I understood, no, they shouldn't be disabled. I will definitely have to test on a clean install. Hopefully, the week-end is close. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770706: keystone.service does not start, /var/run/keystone not created
On 12/04/2014 03:52 AM, Thomas Goirand wrote: Let's see what the release team says. Thanks Thomas. Aside from this, I took a look at how they did in Fedora. Here is their unit file: [Unit] Description=OpenStack Identity Service (code-named Keystone) After=syslog.target network.target [Service] Type=notify Restart=always User=keystone ExecStart=/usr/bin/keystone-all --config-file /usr/share/keystone/keystone-dist.conf --config-file /etc/keystone/keystone.conf [Install] WantedBy=multi-user.target So, we can use multiple config files, this allows the same granularity as the /etc/default/* way. They also use the Type=notify clause. Their keystone-dist.conf has the following DEFAULT section: [DEFAULT] log_file = /var/log/keystone/keystone.log onready = keystone.common.systemd To mimic the current genericity of our init-script, we could use something like ExecStart=... --config-file /usr/share/keystone/keystone-systemd.conf --config-file /etc/openstack.conf --config-file /etc/keystone/keystone.conf 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. Obviously, this is for post-jessie anyway. Cheers, Mikaël. -- 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: Bug#770706: keystone.service does not start, /var/run/keystone not created
Hi Gaudenz,
I will focus on the so called minimal set for now. If you don't mind,
we will open another bug to improve systemd's integration after this one
is fixed.
On 12/03/2014 04:58 AM, Gaudenz Steinlin wrote:
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 did with keystone but developper tests are never to be trusted ;-) Its
quite easy to test BTW, as root:
apt-get build-dep openstack-pkg-tools
git clone -b debian/unstable
https://github.com/MikaelCluseau/debian-openstack-pkg-tools.git
cd debian-openstack-pkg-tools
debuild -us -uc -b
dpkg -i ../openstack-pkg-tools_19_all.deb
Then you can build any other OpenStack package from source. For
instance, keystone:
apt-get source keystone
cd keystone-*/
debuild -us -uc -b
dpkg -i ../keystone_*.deb
There's a long test phase during the build, maybe Thomas can suggest a
trick to avoid it :-)
What do you mean by dangerous choices?
Thomas considered the choice of not creating /var/lock/* dangerous.
If we really need them they have
to be created by systemd and sysv init scripts as /var/lock is a symlink
into /run which is typically a tmpfs.
This is included in my last patch proposal.
Do you have a complete patch (including the recent discussion) which
can be applied to openstack-pkg-tools and used to rebuild test
packages? I think this needs thorough testing if it's to be proposed
for jessie.
As I said at the beginning, yes. Here the complete patch for the
immediate review:
± git log -1 --stat -p
commit 8b3217905de88f2037f0bbc6eac46dca776c8f48
Author: Mikaël Cluseau mclus...@isi.nc
Date: Sun Nov 30 18:45:25 2014 +1100
Fix for bug #770706
---
init-template/init-script-template | 23 +--
init-template/pkgos-gen-systemd-unit | 10 +-
2 files changed, 18 insertions(+), 15 deletions(-)
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..4c41ef0 100755
--- a/init-template/pkgos-gen-systemd-unit
+++ b/init-template/pkgos-gen-systemd-unit
@@ -12,7 +12,7 @@ fi
if [ -z ${SYSTEM_USER} ] ; then
SYSTEM_USER=${PROJECT_NAME}
fi
-if [ -z ${SYSTEM_USER} ] ; then
+if [ -z ${SYSTEM_GROUP} ] ; then
SYSTEM_GROUP=${PROJECT_NAME}
fi
@@ -33,12 +33,12 @@ $AFTER
[Service]
User=${SYSTEM_USER}
Group=${SYSTEM_GROUP}
+WorkingDirectory=/var/lib/${PROJECT_NAME}
+PermissionsStartOnly=true
+ExecStartPre=/bin/mkdir -p /var/lock/${PROJECT_NAME}
/var/log/${PROJECT_NAME} /var/lib/${PROJECT_NAME}
+ExecStartPre=/bin/chown ${SYSTEM_USER}:${SYSTEM_GROUP}
/var/lock/${PROJECT_NAME} /var/log/${PROJECT_NAME} /var/lib/${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: keystone.service does not start, /var/run/keystone not created
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.
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.
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.
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 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
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 and create
/var/log/${PROJECT_NAME} at install time (that whould even fix this bug
without having to change a line in the unit and the sysv-rc script).
I do believe that the /var/lock/${PROJECT_NAME} is needed in some cases
for the internals of OpenStack. I would find it dangerous to remove
it.
Then we have to find out which ones use it and create it for those
services. At least IMO.
I prefer to avoid dangerous choices; its not expensive to have these
created. But then, should they be created by systemd or at install time?
(Thomas?)
So we all agree on this. From here at least for me it follows that the
non working unit files should be removed as soon as possible. If we can
come up with a solution without relying on the sysv init script and that
is acceptable for the Release team, then good. Otherwise the second best
option IMO is to use the sysv support in systemd and not ship any unit
files.
I think my previous work (keeping the init-script) can be accepted by
the release team and is a significant step toward the systemd's way as
it avoids start-stop-daemon. I will add the missing auto-created folders
to keep closer to the original script.
--
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: Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created
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
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: Info received ([PKG-Openstack-devel] Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created)
Sorry, I forgot to change the WorkingDirectory to fully comply with the
start-stop-daemon line. The patch for the unit file should be:
diff --git a/init-template/pkgos-gen-systemd-unit
b/init-template/pkgos-gen-systemd-unit
index b97e2a9..8700b6c 100755
--- a/init-template/pkgos-gen-systemd-unit
+++ b/init-template/pkgos-gen-systemd-unit
@@ -33,12 +33,12 @@ $AFTER
[Service]
User=${SYSTEM_USER}
Group=${SYSTEM_GROUP}
+WorkingDirectory=/var/lib/${PROJECT_NAME}
+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: Bug#770706: keystone.service does not start, /var/run/keystone not created
On 11/27/2014 06:08 PM, Gaudenz Steinlin wrote: I think we can agree that *if* we implement the systemd fully *then* pid-files become useless. As you say it would be the best way, I would like to (try to) spend a significant time to implement the systemd way this week-end. Just... I don't want to it just for the trash, so I'd like to know if you'd agree with this and if the release team will (probably) accept it, or not. I agree with the pidfile part. I can't comment on the release team. If that's important to you best ask them yourself. But even if this does not end up in jessie we need this for the future. So work in this is definitely not lost. Maybe you could also implement some of the security features that systemd provides[1] in the unit files. But that's probably more than the Release Team is willing to accept. Gaudenz [1] http://0pointer.net/public/systemd-nluug-2014.pdf Thank you for the suggestions. I will try to implements things in 2 parts, I think it's better that to believe I can fool the release team with a big commit :-) After many years, it's the first time I try to contribute to Debian, so I'll rely heavily on comments. Let's try! -- 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: Bug#770706: keystone.service does not start, /var/run/keystone not created
The quick-fix of tmpfiles.d is what I did first and will (probably) work. But, if I assemble this On 11/27/2014 11:10 AM, Thomas Goirand wrote: 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. and this On 11/27/2014 11:14 AM, Thomas Goirand wrote: Best would be if we could just get rid of the sysv-rc wrapper, and just go the systemd way fully. I think we can agree that *if* we implement the systemd fully *then* pid-files become useless. As you say it would be the best way, I would like to (try to) spend a significant time to implement the systemd way this week-end. Just... I don't want to it just for the trash, so I'd like to know if you'd agree with this and if the release team will (probably) accept it, or not. -- 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: Bug#770706: keystone.service does not start, /var/run/keystone not created
On 24/11/2014 10:20, Thomas Goirand wrote: 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. I will try to help. I didn't knew if the intention was to keep a simple compatibility for systems without systemd. I'm GMT+11. Do you prefer to track on this bug or on #767711? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767711: openstack-pkg-tools: systemd start fails a fresh install
Hi Thomas,
On 11/11/2014 10:36 AM, Thomas Goirand wrote:
I have uploaded version 19 of openstack-pkg-tools, which fixes the
issue. The way to fix it is to do:
RuntimeDirectory=${PROJECT_NAME}
as per the systemd manpages, and per what the guys in #debian-systemd
adviced.
Systemd is awesome: of course, they though about the fact that /run or
/var/run is standard and doesn't have to be repeated in each unit...
Thanks for fixing :-)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767711: openstack-pkg-tools: systemd start fails a fresh install
On 11/02/2014 12:54 PM, Mikael Cluseau wrote:
+RuntimeDirectory=/var/run/${PROJECT_NAME}
This is not ok, systemd says its invalid. It needs to be :
+RuntimeDirectory=/run/${PROJECT_NAME}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
