Bug#764607: systemd: systemctl does not re-create display-manager.service symlink
Le 22/11/2014 21:28, Andrei POPESCU a écrit : 2b. Each display manager must add a Conflicts=[all other DMs] You don't really need to maintain a long list of Conflicts (which will never be kept up to date). I suggested last wek to the gdm maintainers that we start using the Alias. That enables to have only one DM enable at a time, having systemctl creating the symlink and conflicting when needed. Finally, the postinst maintainer script is easier. Then, you don't really need WantedBy=graphical.target I guess. I didn't hear from the gdm3-pkg team yet, let me paste my suggestions: --- We discussed a little bit today with Martin on providing other display managers like xdm with systemd services. I looked at the existing postinst of lightdm and I think we can leverage systemd Alias to keep the exact same functionality, but removing the internal systemd knowledge from the postinst scripts. The end result on disk would be exactly the same than the existing implementation, we just remove the manual handling of symlinks. The idea is to add: [Install] Alias=display-manager.service to the service unit, and then, replacing the existing postinst symlinks dance with only systemctl commands. Here is the commit for lightdm: http://bazaar.launchpad.net/~didrocks/lightdm/systemd-alias/revision/2099, resulting in a simpler postinst: http://bazaar.launchpad.net/~didrocks/lightdm/systemd-alias/view/head:/debian/lightdm.postinst#L72 Martin agrees that this approach is more decouple from systemd internals and I'm here to reach your feedback about it. As the result on disk is the same in the end, we don't have to migrate all DMs at the same time if you agree with that idea. I've prepared in case you are in favor of this change a gdm3 debdiif (attached), I saw that upstream was shipping for gdm the Alias section, so modified the patch + postinst for it. - Does it make sense to you? diff -Nru gdm3-3.14.1/debian/changelog gdm3-3.14.1/debian/changelog --- gdm3-3.14.1/debian/changelog2014-11-09 18:16:03.0 +0100 +++ gdm3-3.14.1/debian/changelog2014-11-20 09:44:14.0 +0100 @@ -1,3 +1,10 @@ +gdm3 (3.14.1-4) UNRELEASED; urgency=medium + + * debian/patches/92_systemd_unit.patch, debian/gdm3.postinst: +- Using Alias and systemctl to handle systemd unit alternatives. + + -- Didier Roche didro...@ubuntu.com Thu, 20 Nov 2014 09:40:25 +0100 + gdm3 (3.14.1-3) unstable; urgency=medium * 18_all_displays_transient.patch: fix autologin for the initial diff -Nru gdm3-3.14.1/debian/gdm3.postinst gdm3-3.14.1/debian/gdm3.postinst --- gdm3-3.14.1/debian/gdm3.postinst2014-04-27 15:07:16.0 +0200 +++ gdm3-3.14.1/debian/gdm3.postinst2014-11-20 09:45:01.0 +0100 @@ -40,21 +40,18 @@ fi fi -DEFAULT_SERVICE=/etc/systemd/system/display-manager.service +DEFAULT_SERVICE=display-manager.service +SERVICE=$(basename $(cat $DEFAULT_DISPLAY_MANAGER_FILE)).service # set default-display-manager systemd service link according to our config -if [ $1 = configure ] [ -d /etc/systemd/system/ ]; then - if [ -e $DEFAULT_DISPLAY_MANAGER_FILE ]; then -SERVICE=/lib/systemd/system/$(basename $(cat $DEFAULT_DISPLAY_MANAGER_FILE)).service -if [ -h $DEFAULT_SERVICE ] [ $(readlink $DEFAULT_SERVICE) = /dev/null ]; then - echo Display manager service is masked 2 -elif [ -e $SERVICE ]; then - ln -sf $SERVICE $DEFAULT_SERVICE -else - echo WARNING: $SERVICE is the selected default display manager but does not exist 2 - rm -f $DEFAULT_SERVICE -fi +if [ $1 = configure ] [ -x /bin/systemctl ]; then + if [ $(systemctl is-enabled $DEFAULT_SERVICE) = masked ]; then +echo Display manager service is masked 2 else -rm -f $DEFAULT_SERVICE +[ -d /run/systemd/system ] systemctl daemon-reload +systemctl enable --force $SERVICE 2/dev/null || true +if [ $? != 0 ]; then + echo WARNING: $SERVICE is the selected default display manager but does not have a systemd service 2 +fi fi fi diff -Nru gdm3-3.14.1/debian/patches/92_systemd_unit.patch gdm3-3.14.1/debian/patches/92_systemd_unit.patch --- gdm3-3.14.1/debian/patches/92_systemd_unit.patch2014-04-27 14:44:32.0 +0200 +++ gdm3-3.14.1/debian/patches/92_systemd_unit.patch2014-11-20 09:43:34.0 +0100 @@ -1,8 +1,8 @@ -Index: gdm3-3.12.1/data/gdm.service.in +Index: gdm3-3.14.1/data/gdm.service.in === gdm3-3.12.1.orig/data/gdm.service.in 2014-04-27 14:40:14.210580120 +0200 -+++ gdm3-3.12.1/data/gdm.service.in2014-04-27 14:43:22.350149176 +0200 -@@ -4,12 +4,15 @@ Conflicts=getty@tty@GDM_INITIAL_VT@.serv +--- gdm3-3.14.1.orig/data/gdm.service.in gdm3-3.14.1/data/gdm.service.in +@@ -4,10 +4,16 @@ Conflicts=getty@tty@GDM_INITIAL_VT@.serv After=systemd-user-sessions.service getty@tty@GDM_INITIAL_VT@.service plymouth-quit.service
Bug#770633: systemd: Suggestion for a method to handle multiple providers of the same service
Le 22/11/2014 21:25, Andrei POPESCU a écrit : Package: systemd Version: 215-6 Severity: wishlist Tags: upstream Hello, I think systemd needs a method to deal with multiple providers of the same service that under usual circumstances (i.e. default configuration) can't run at the same time, e.g. display managers. Here's what I came up with, as possible addition to systemd.unit(5) --- [INSTALL] SECTION OPTIONS AlternativeFor= The name of a service this unit provides, of which there might be several providers that can't (under normal circumstances) run at the same time. At installation time systemctl enable will only create symlinks from this name to the unit filename, with the same suffix as this unit. This option implies a Conflicts= against all other providers of the same service. --- I think this would be quite simple to implement and is generic enough to be used for all kinds of services. Hey, See my answer on bug #764607, I think the Alias permits us to achieve this, in a same way we have alternatives. Then, it requires that the target Wants=this alternative though. Cheers, Didier ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Starting a service when stopping a different one
What is the underlying problem you're trying to solve? That one daemon (namely wd_keepalive) needs to be started when another daemon (namely watchdog) is stopped. The reason for that is that if the kernel is configured with NOWAYOUT stopping watchdog will result in a reset, maybe before shutdown is completed. wd_keepalive prevents that by petting the watchdog some more. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#764607: systemd: systemctl does not re-create display-manager.service symlink
Here is an updated version of the patch (ensuring we echo a warning if systemctl enable fails) after discussing with Laurent. There seems to be one case failing due to the autogenerated gdm3 service script from the LSB version which is making systemctl enable --force gdm3 failing, investigating. Cheers, Didier diff -Nru gdm3-3.14.1/debian/changelog gdm3-3.14.1/debian/changelog --- gdm3-3.14.1/debian/changelog2014-11-09 18:16:03.0 +0100 +++ gdm3-3.14.1/debian/changelog2014-11-20 09:44:14.0 +0100 @@ -1,3 +1,11 @@ +gdm3 (3.14.1-4) UNRELEASED; urgency=medium + + * debian/patches/92_systemd_unit.patch, debian/gdm3.postinst: +- Using Alias and systemctl to handle systemd unit alternatives. + Closes: #764607 + + -- Didier Roche didro...@ubuntu.com Thu, 20 Nov 2014 09:40:25 +0100 + gdm3 (3.14.1-3) unstable; urgency=medium * 18_all_displays_transient.patch: fix autologin for the initial diff -Nru gdm3-3.14.1/debian/gdm3.postinst gdm3-3.14.1/debian/gdm3.postinst --- gdm3-3.14.1/debian/gdm3.postinst2014-04-27 15:07:16.0 +0200 +++ gdm3-3.14.1/debian/gdm3.postinst2014-11-20 09:45:01.0 +0100 @@ -40,21 +40,17 @@ fi fi -DEFAULT_SERVICE=/etc/systemd/system/display-manager.service +DEFAULT_SERVICE=display-manager.service +SERVICE=$(basename $(cat $DEFAULT_DISPLAY_MANAGER_FILE)).service # set default-display-manager systemd service link according to our config -if [ $1 = configure ] [ -d /etc/systemd/system/ ]; then - if [ -e $DEFAULT_DISPLAY_MANAGER_FILE ]; then -SERVICE=/lib/systemd/system/$(basename $(cat $DEFAULT_DISPLAY_MANAGER_FILE)).service -if [ -h $DEFAULT_SERVICE ] [ $(readlink $DEFAULT_SERVICE) = /dev/null ]; then - echo Display manager service is masked 2 -elif [ -e $SERVICE ]; then - ln -sf $SERVICE $DEFAULT_SERVICE -else - echo WARNING: $SERVICE is the selected default display manager but does not exist 2 - rm -f $DEFAULT_SERVICE -fi +if [ $1 = configure ] [ -x /bin/systemctl ]; then + if [ $(systemctl is-enabled $DEFAULT_SERVICE) = masked ]; then +echo Display manager service is masked 2 else -rm -f $DEFAULT_SERVICE +[ -d /run/systemd/system ] systemctl daemon-reload +if [ ! `systemctl enable --force $SERVICE 2/dev/null` ]; then + echo WARNING: $SERVICE is the selected default display manager but does not have a systemd service 2 +fi fi fi diff -Nru gdm3-3.14.1/debian/patches/92_systemd_unit.patch gdm3-3.14.1/debian/patches/92_systemd_unit.patch --- gdm3-3.14.1/debian/patches/92_systemd_unit.patch2014-04-27 14:44:32.0 +0200 +++ gdm3-3.14.1/debian/patches/92_systemd_unit.patch2014-11-20 09:43:34.0 +0100 @@ -1,8 +1,8 @@ -Index: gdm3-3.12.1/data/gdm.service.in +Index: gdm3-3.14.1/data/gdm.service.in === gdm3-3.12.1.orig/data/gdm.service.in 2014-04-27 14:40:14.210580120 +0200 -+++ gdm3-3.12.1/data/gdm.service.in2014-04-27 14:43:22.350149176 +0200 -@@ -4,12 +4,15 @@ Conflicts=getty@tty@GDM_INITIAL_VT@.serv +--- gdm3-3.14.1.orig/data/gdm.service.in gdm3-3.14.1/data/gdm.service.in +@@ -4,10 +4,16 @@ Conflicts=getty@tty@GDM_INITIAL_VT@.serv After=systemd-user-sessions.service getty@tty@GDM_INITIAL_VT@.service plymouth-quit.service [Service] @@ -20,6 +20,4 @@ +#BusName=org.gnome.DisplayManager StandardOutput=syslog StandardError=inherit -- --[Install] --Alias=display-manager.service + ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Bug#766233: LXC breakage and workarounds when upgrading VMs to jessie
On Mon, Nov 24, 2014 at 07:48:28AM +0100, Tomas Pospisek wrote: On Mon, 24 Nov 2014, Marco d'Itri wrote: On Nov 24, Tomas Pospisek tpo_...@sourcepole.ch wrote: My first proposed text for the release-notes is below. Please let me know if you prefer me to submit a proper patch against a SVN checkout of ddp. Please also clarify that LXC containers *can* use systemd with no troubles if correctly configured. Could you please clarify what needs to be done to correctly configure a LXC container? This: https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-November/010900.html I am interacting with Daniel (Debian maintainer) to also get that into jessie. * Is it sufficient to set: lxc.autodev = 1 in /var/lib/lxc/myvm/config? Definitively not. * Does an upgrade also automatically switch to journald? * In which case one *must* also set lxc.kmsg=0 in /var/lib/lxc/myvm/config and remove /dev/kmsg inside the VM? * Is it possible to switch a system configured in such a way back and forth between systemd and sysvinit without having to change anything but the package selection? Or does that imply removing the configuration changes, i.e. removing lxc.autodev = 1 and lxc.kmsg=0 and recreating /dev/kmsg? * Is it possible to run the upgraded VM, that is correctly configured as you suggest on a normal wheezy host? Does the wheezy host need any special configuration? I don't have answers for these questions yet. -- Antonio Terceiro terce...@debian.org signature.asc Description: Digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#768577: Patch applied upstream
Hi, For your information, a patch has been applied upstream. Here is the link: http://cgit.freedesktop.org/systemd/systemd/commit/?id=8a52210c93 Cheers, Quentin ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: [bts-link] source package systemd
Processing commands for cont...@bugs.debian.org: # # bts-link upstream status pull for source package systemd # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org Setting user to bts-link-upstr...@lists.alioth.debian.org (was bts-link-de...@lists.alioth.debian.org). # remote status report for #768577 (http://bugs.debian.org/768577) # Bug title: systemd-cryptsetup handles keyfile differently from cryptsetup on plain mode # * https://bugs.freedesktop.org/show_bug.cgi?id=52630 # * remote status changed: NEW - RESOLVED # * remote resolution changed: (?) - NOTOURBUG # * closed upstream tags 768577 + fixed-upstream Bug #768577 [systemd] systemd-cryptsetup handles keyfile differently from cryptsetup on plain mode Added tag(s) fixed-upstream. usertags 768577 - status-NEW Usertags were: status-NEW. Usertags are now: . usertags 768577 + status-RESOLVED resolution-NOTOURBUG There were no usertags set. Usertags are now: status-RESOLVED resolution-NOTOURBUG. thanks Stopping processing here. Please contact me if you need assistance. -- 768577: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768577 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: Re: Bug#770275: nspawn units a bit hard to get working
Processing control commands: tag -1 fixed-upstream Bug #770275 [systemd] nspawn units a bit hard to get working Added tag(s) fixed-upstream. -- 770275: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770275 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#768577: Patch applied upstream
Hi, On 24/11/2014 16:37, intrigeri wrote : Quentin Lefebvre wrote (24 Nov 2014 14:35:45 GMT) : For your information, a patch has been applied upstream. Here is the link: http://cgit.freedesktop.org/systemd/systemd/commit/?id=8a52210c93 Congrats! Can you please try to apply the upstream patch on top of Debian unstable's systemd, and confirm that it works and fixes the issue for you? Thanks for making me test the new patch. Actually it is a rewrite of the one I first proposed, and it doesn't work. I hope the developers will agree on my original patch. So... waiting! Cheers, Quentin ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#770633: systemd: Suggestion for a method to handle multiple providers of the same service
On Lu, 24 nov 14, 09:26:00, Didier Roche wrote: See my answer on bug #764607, I think the Alias permits us to achieve this, in a same way we have alternatives. Then, it requires that the target Wants=this alternative though. This didn't seem to work so well when lxdm declared Alias=display-manager.service. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770404 Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#768577: Patch applied upstream
So here is the point of view of the developers. The upstream patch works provided that hash=plain is mentioned in /etc/cryptab. To summarize: - when a user creates a plain dm-crypt device providing a --hash parameter along with a key file - he *should* be aware of the fact that the hash parameter is ignored - and as a consequence, he should write hash=plain in /etc/crypttab - in short, it's a cryptsetup bug, and systemd won't be compatible with cryptsetup's bug... Let's say that's fine. It may be worth documenting this. Please note that this patch basically changes nothing about the aforementioned bug, so I'm not convinced it should be applied in Debian, and I don't attach it. The trick with hash=plain already works with Debian's current version of systemd. Best regards, Quentin ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: The inittab interface - Re: Bug#766187: runit: Fails to install runit after fresh install of jessie beta2
On 24/11/14 21:41, Gerrit Pape wrote: Better than (2) would be to make the existence of /etc/inittab still essential for jessie, by moving the corresponding code from sysvinit-core into the essential init package. What do you think? If you go this route, I think initscripts might be a better home for inittab. It is depended on by all our supported pid 1 implementations - sysvinit-core, systemd-sysv (via systemd) and upstart - and comes from the same source package as sysvinit, which init does not. S ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#770886: systemd-sysv: Silence on shutdown; sytem hangs without any indication why
Package: systemd-sysv Version: 215-5+b1 Severity: important At shutdown or reboot time, after X dies, the screen is just black. I see no updates. I see no status. No nothing. This was not the case with sysvinit (as each service was stopped, status was displayed). Is this normal under sytemd? (Should it be?) I've had my system hang during shutdown but have no idea how to fix it. John -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd-sysv depends on: ii systemd 215-5+b1 systemd-sysv recommends no packages. systemd-sysv suggests no packages. -- no debconf information ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: severity of 770644 is important
Processing commands for cont...@bugs.debian.org: severity 770644 important Bug #770644 [systemd] systemd: systemd is completely unusable after a fatal signal Severity set to 'important' from 'serious' thanks Stopping processing here. Please contact me if you need assistance. -- 770644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770644 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: found 770644 in 215-1
Processing commands for cont...@bugs.debian.org: found 770644 215-1 Bug #770644 [systemd] systemd: systemd is completely unusable after a fatal signal Marked as found in versions systemd/215-1. thanks Stopping processing here. Please contact me if you need assistance. -- 770644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770644 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: tagging 770734
Processing commands for cont...@bugs.debian.org: tags 770734 + moreinfo unreproducible Bug #770734 [src:systemd] systemd: FTBFS in environment with all packages rebuilt locally Added tag(s) unreproducible and moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 770734: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770734 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#770633: systemd: Suggestion for a method to handle multiple providers of the same service
Le 24/11/2014 20:24, Andrei POPESCU a écrit : On Lu, 24 nov 14, 09:26:00, Didier Roche wrote: See my answer on bug #764607, I think the Alias permits us to achieve this, in a same way we have alternatives. Then, it requires that the target Wants=this alternative though. This didn't seem to work so well when lxdm declared Alias=display-manager.service. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770404 It seems they didn't use the postinst snippet I advised about (hence the symlink not being updated). ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
