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
Thomas Goirand writes: > I have found out what happened. Indeed, this issue is that we're not > calling dh_systemd_enable. Or rather, openstack-pkg-tools is generating > the *.service files in the override_dh_installinit target, which happens > after the dh_systemd_enable in the standard dh sequence. So I wrote this: > ># Generate the systemd unit file ># Note: because dh_systemd_enable is called by the ># dh sequencer *before* dh_installinit, we have ># to process it manually. >for i in `ls debian/*.init.in` ; do \ > pkgos-gen-systemd-unit $$i ; \ > MYSERVICE=`echo $$i | sed 's/debian\///'` ; \ > MYSERVICE=`echo $$MYSERVICE | sed 's/.init.in/.service/'` ; \ > dh_systemd_enable $$MYSERVICE ; \ >done > > in the override_dh_installinit. I don't see a reason why this should not work, but I wonder why you don't just add an override_dh_systemd_enable target wich first uses pkgos to generate the service files and then just calls dh_systemd_enable. This seems like the more obvious solution to me. Having this in a separate target would probably also make it possible to build packages without systemd by just not build depending on dh-systemd. > This works, then, except for keystone > where there's no #DEBHELPER# in the postinst (because I wanted to keep > the control of when invoke-rc.d is called, ie after the daemon starts, > the admin tenant is created, and the keystone endpoint is registered). > This means that for Keystone, we need to manually add what > dh_systemd_enable does. Then I've been asking myself what would happen > in Wheezy, and it's looking like the only thing that will happen is that > it's going to add a dependency on init-system-helpers, which IMO is > quite fine, because it's already available from the official > wheezy-backports. I don't understand the problem you are trying to solve here. Why are you not just adding the #DEBHELPER# at the end of the postinst where you want it to be? I don't see how the debhelper inserted snippets don't give you control over where they are called. But maybe I'm missing something. Gaudenz -- 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: 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: Bug#770706: keystone.service does not start, /var/run/keystone not created
Thomas Goirand writes: > On 12/05/2014 03:04 AM, Gaudenz Steinlin wrote: >> OK I tested keystone on unstable now and this works as it should. It's >> definitely an improvement over the current unit file which does not work >> at all. > > Cool, thanks for your time! > >> 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? >> >> Gaudenz > > This is a bug. With sysinit, it starts by default. What did you have to > do under systemd to make it start? To make the services start on boot you have to manually enable them with systemctl enable *sercicename*. You can stil start them manually with systemctl start *servicename* and they work fine, even if they are disabled. I don't know why they are not enabled by default, but suspect it's because that's because you don't run dh_systemd_enable during the package build or something similar. Gaudenz -- 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: Bug#770706: keystone.service does not start, /var/run/keystone not created
On 12/01/2014 05:12 AM, Mikaël Cluseau wrote:
> 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.
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. For example, if you use the configuration
file for Glance, it will affect both the glance-registry and the
glance-api daemon. With the /etc/default system, you can do it for only
one of the daemons if you like. Also, the /etc/default/openstack can be
global to *all* of OpenStack services, which you cannot do with all
configuration files (well, you can, but then you have to edit each and
every service configuration file, which is really annoying).
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.
>> 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.
No, it's not ${PROJECT_NAME}, but the daemon name!!!
>>> 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.
It's up to the operator to choose. Some would like to keep a per-daemon
log, especially because otherwise, it can fill your syslog very fast.
And also, consider the fact that journald is really bad performance
wise, then you don't really want to fill-it-up with huge debug logs.
>>> 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.
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.
>> 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 :-)
Yup, me as well.
>> 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.
I do think it's better to keep the same user interface for both systemd
and sysv-rc.
Cheers,
Thomas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
