Bug#783509: systemd: /tmp purged on every reboot
Le 28/04/2015 01:11, Michael Biebl a écrit : Am 27.04.2015 um 21:56 schrieb Michael Biebl: Ok, I can confirm that adding such a bind mount to /tmp activates tmp.mount, even if tmp.mount has been disabled. Retitling the bug report accordingly. I can also confirm, that this is a regression from -12 to -13 by installing those two versions from snapshot.d.o. I did a test build with debian/patches/PrivateTmp-shouldn-t-require-tmpfs.patch reverted, and that seems indeed to fix this particular issue. Interesting side-effect. Didier, any idea? It's a weird side-effect indeed. The patch only downgrades the relationship with this mount, which already exists in systemd mem. I have no immediate idea what's happening there and a quick look at the code this morning didn't help either. ___ 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#779902: /tmp can be mounted as tmpfs against user's will
Le 20/03/2015 08:39, Michael Biebl a écrit : Am 20.03.2015 um 08:26 schrieb Didier Roche: Hey, Attaching the patch (which tries to be less intrusive with mounts, only affecting /tmp) that I pinged on IRC for better tracking. Tested under multiple configurations. /tmp isn't mounted as tmpfs neither at boot, nor after a service restart having PrivateTmp. Enabling the tmp mount unit now ensures that it's started at boot, before services having PrivateTmp. Hi Didier, Hey Michael, thanks for the patch. I had something like this in mind. We could be extra nice and only add the After=tmp.mount if tmp.mount is actually enabled, because we only need the After ordering in this case. But that's mostly a cosmetic issue and I'm happy to ship the patch as is. That's a nice idea. It needs testing though to ensure that the fstab generator generated the right enablement for that unit (in case the tmpfs config was done in fstab). Also, we need to ensure that any later enablement of that unit, this is taken into account by new units. Not sure I'll have time to test this properly today, will be more early next week if needed though. 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
Bug#779902: /tmp can be mounted as tmpfs against user's will
Le 06/03/2015 16:04, Michael Biebl a écrit : Am 06.03.2015 um 10:10 schrieb Martin Pitt: Control: found -1 215-12 Control: tag -1 confirmed Ça va Didier, Didier Roche [2015-03-06 9:36 +0100]: In debian, tmp.mount is disabled through a distro-patch by default. It means we don't want user's system to get /tmp on tmpfs without explicit enablement (either by enabling tmp.mount unit or via fstab). We noticed that starting an unit using PrivateTmp=yes will pull tmp.mount (which mounts /tmp on tmpfs) in its requirements chain (even if this unit is condition fail). Confirmed. systemctl start colord or systemd-timesyncd will start tmp.mount and thus overmount the existing /tmp in the running system. I reproduced that in a clean sid VM (with LXDE, but I suppose that doesn't matter much). The odd thing though is, that PrivateTmp=yes does not trigger the start of tmp.mount during boot at least on all the test systems I have. Do we know, why that is? A Required=tmp.mount should always start the referenced unit, but it seemingly doesn't. For reference, I dig a little bit into it and asked on the upstream ML: http://lists.freedesktop.org/archives/systemd-devel/2015-March/029072.html Let's see if the bug we are seeing is really due to tmp.mount not being explicitly referenced anywhere. ___ 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#779902: /tmp can be mounted as tmpfs against user's will
Package: systemd Severity: serious In debian, tmp.mount is disabled through a distro-patch by default. It means we don't want user's system to get /tmp on tmpfs without explicit enablement (either by enabling tmp.mount unit or via fstab). We noticed that starting an unit using PrivateTmp=yes will pull tmp.mount (which mounts /tmp on tmpfs) in its requirements chain (even if this unit is condition fail). For instance: systemctl show -p Requires -p RequiresMountsFor systemd-timesyncd.service Requires=-.mount tmp.mount RequiresMountsFor=/var/lib/systemd/clock /tmp /var/tmp Note that multiple units are using the private tmp feature like cups. Also, if the unit is restarted (like an upgrade involving cups), /tmp will as well be remounted as tmpfs, which can wipe /tmp content to new process and get some annoying side-effects. We need to find a way to ensure that tmp.mount is never accidentally trigger, while still enabling the user using fstab to enable /tmp as tmpfs. Enabling the unit to get the same effect would be a nice addition. ___ 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#771653: systemd 217 breaks X11 (not more kdm and loggin and using startx gives me no mouse)
Le 02/12/2014 09:01, Eric Valette a écrit : On 02/12/2014 08:55, Didier Roche wrote: This isn't the logs we asked for though to debug your issue. Can you paste them please? (after running as root): systemctl status kdm.service systemctl status display-manager.service Here they are (making them from console :-() -- eric Thanks! Are you really sure that /etc/X11/default-display-manager exists on this machine (you didn't paste from any other) and points to a kdm binary? If so, do you mind if I give you a debug version of a binary (you can revert to previous systemd meanwhile), so that I can get the needed informations to know what happens (I would need to know your machine architecture then). 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
Bug#771653: systemd 217 breaks X11 (not more kdm and loggin and using startx gives me no mouse)
Le 02/12/2014 09:17, Eric Valette a écrit : On 02/12/2014 09:13, Didier Roche wrote: anks! Are you really sure that /etc/X11/default-display-manager exists on this machine (you didn't paste from any other) and points to a kdm binary? Yes. Double checked! cat /etc/X11/default-display-manager /usr/bin/kdm valette@tri-yann4:~$ type /usr/bin/kdm /usr/bin/kdm est /usr/bin/kdm valette@tri-yann4:~$ file /usr/bin/kdm /usr/bin/kdm: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=e0e10507ede6d64eab115388829af4e23f8938c5, stripped Ok, everything looks fine. I doubt about the /usr separation to be the cause for that one as the generator doesn't use any file there. Last try before sending you a debug binary: cat -e /etc/X11/default-display-manager (even if I treat trailing spaces, \n and so on, let's see…) and: ls -l /etc/systemd/system/ ls -l /run/systemd/generator* 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
Bug#771739: could not start nodm with systemd 217-1 or 217-2
Le 02/12/2014 12:28, Michael Biebl a écrit : Am 02.12.2014 um 06:48 schrieb Martin Pitt: 積丹尼 Dan Jacobson [2014-12-02 13:36 +0800]: # cat /etc/X11/default-display-manager cat: /etc/X11/default-display-manager: No such file or directory Indeed, nodm doesn't use this file at all, nor does it conflict with any other window manager. So installing nodm together with gdm, lightdm, kdm, etc. will just result in a disaster :-( Didier, I'm afraid we have to exclude nodm from your DM masking -- I don't see a way how we can fix this without actually fixing nodm. I'm not sure if the generator is a good idea. I played around with that idea a long time ago but discarded it again. It seems the way Lennart advertised the use of a default configuration (like in /e/X/d-d-m) keeping in sync with Aliases like display-manager.service. It also changes the behaviour of the insserv generator, which no longer generates dependencies if native units exist. systemd does that itself as well anyway (I didn't put that on the overriding stack on purpose). I can condition that masking for display-manager only if you feel more comfortable that way. Note that this patch modification is for jessie-only and should be removed as being useless as soon as all dms ship systemd units. At the current stage, I don't think these patches should be merged as is for master. Didier, Martin: could you elaborate what those patches try to fix? This is to fix multiple bug reports where people don't have (or have multiple) dm services starting. Also, it enables people changing manually /e/X/d-d-m to not reboot in a state where no dm is started. The use case is to ensure that display-manager.service will always points to a systemd service that will be runnable (if any). Meaning that we won't have failing units due to ExecStartPre failing and having that shell execution, or disable them if there is an init dm matching. It's going to enable us as well to migrate to Alias=display-manager.service one dm service after another instead in jessie+1 than doing the transition in a batch. Precise behavior in coordination to the 2 generators is: - if /etc/X11/default-display-manager matches a systemd unit and matches display-manager.service: - noop on the systemd side, mask all dms sysvinit not matching a systemd unit - if /etc/X11/default-display-manager matches systemd unit and but doesn't match what's pointed by display-manager.service: - we ensure display-manager.service transiantly points to correct systemd unit, we mask all dms sysvinit not matching a systemd unit - if /etc/X11/default-display-manager matches a non systemd unit: - we transiently mask display-manager.service (so no systemd unit startup) and mask all sysvinit dm scripts, but the one matching /etc/X11/default-display-manager - if no /etc/X11/default-display-manager: - we even don't look at the systemd side (we hope there will be one display-manager.service matching at least one), we mask all sysvinit dm scripts The last case is what is at fault here. I would suggest that we change the patch: - if /etc/X11/default-display-manager matches anything at all or doesn't exist, we avoid masking any sysvinit dm script if there is no display-manager.service matching a real service file. 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
Bug#771739: could not start nodm with systemd 217-1 or 217-2
Le 02/12/2014 13:44, Michael Biebl a écrit : Am 02.12.2014 um 13:06 schrieb Didier Roche: This is to fix multiple bug reports where people don't have (or have multiple) dm services starting. Can you provide links to such bug reports so we have a bit of a context? Sure: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748668 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770404 in particular. Those generators will enable in jessie+1 to implement something like in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764607 without needing all DM to transition to this scheme. ___ 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#771739: could not start nodm with systemd 217-1 or 217-2
Le 02/12/2014 14:33, Michael Biebl a écrit : Am 02.12.2014 um 14:17 schrieb Didier Roche: Le 02/12/2014 13:44, Michael Biebl a écrit : Am 02.12.2014 um 13:06 schrieb Didier Roche: This is to fix multiple bug reports where people don't have (or have multiple) dm services starting. Can you provide links to such bug reports so we have a bit of a context? Sure: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748668 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770404 in particular. Those are bugs in the lxdm and slim packages and need to be fixed there. Trying to workaround that in systemd looks like the wrong approach. Hence my first patch about it, however, bigon asked the release team which nacked doing this for jessie. That's why I'm telling this patch is intended to be a bandaid until we get there. Those generators will enable in jessie+1 to implement something like in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764607 without needing all DM to transition to this scheme. What exactly do you mean with this scheme? Are you referring to having native .service files ship an Alias=display-manager.service in their [Install] section? Exactly, as intended upstream and done in other distributions. ___ 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#771653: systemd 217 breaks X11 (not more kdm and loggin and using startx gives me no mouse)
Control: severity -1 important Control: tag -1 moreinfo Hey, I tried this morning on a vm (with multiple dms installed: lightdm, xdm, gdm and kdm) and when choosing kdm as the alternative to choose in the postinst and checking the status, all seems fine: - all other units are disabled, - display-manager.service is masked (as the default dm is an init script) - generated kdm.service is chosen Do you mind showing the output (as root) of: systemctl status kdm.service systemctl status display-manger.service Thanks! ___ 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#771653: systemd 217 breaks X11 (not more kdm and loggin and using startx gives me no mouse)
Le 02/12/2014 08:47, Eric Valette a écrit : On 02/12/2014 08:16, Didier Roche wrote: Do you mind showing the output (as root) of: systemctl status kdm.service systemctl status display-manger.service I think you are chasing a ghost: even if I log in and restart kdm manually I get no X. And downgrading does solve the problem. Attached is the Xorg.0.log with systemd 215 and Xorg.0.log.ko with 217 This isn't the logs we asked for though to debug your issue. Can you paste them please? (after running as root): systemctl status kdm.service systemctl status display-manager.service Thanks! ___ 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
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
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
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
Bug#769528: Git patch adding ConditionPath on /run/network
Add a ConditionPathIsDirectory on /run/network from ifup@ unit. From 1f747abf9d8351ae4174926255b9b82fccfe6ce2 Mon Sep 17 00:00:00 2001 From: Didier Roche didro...@ubuntu.com Date: Fri, 14 Nov 2014 11:55:24 +0100 Subject: [PATCH] debian/ifup@.service: add a network ConditionPath Add a ConditionPath on /run/network in case autogenerated networking.service didn't need to start and so, didn't create this directory. Starting an ifup service without this directory was resulting in the unit failing. (Closes: # 769528) --- debian/changelog | 7 +++ debian/ifup@.service | 1 + 2 files changed, 8 insertions(+) diff --git a/debian/changelog b/debian/changelog index 49d9328..4215821 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,5 +1,6 @@ systemd (215-6) UNRELEASED; urgency=medium + [ Martin Pitt ] * Cherry-pick upstream patch to fix udev crash in link_config_get(). * Cherry-pick upstream patch to fix tests in limited schroot environments. * Add d/p/Add-env-variable-for-machine-ID-path.patch: Allow specifying an @@ -22,6 +23,12 @@ systemd (215-6) UNRELEASED; urgency=medium required so that tools like systemd-rfkill can be used with SysVinit or upstart scripts, too. (LP: #1387282) + [ Didier Roche ] + * debian/ifup@.service: add a ConditionPath on /run/network in case +autogenerated networking.service didn't need to start (and thus, didn't +create that directory). Starting an ifup service without this directory was +resulting in the unit failing. (Closes: # 769528) + -- Martin Pitt mp...@debian.org Sun, 12 Oct 2014 17:29:00 +0200 systemd (215-5) unstable; urgency=medium diff --git a/debian/ifup@.service b/debian/ifup@.service index c7b2736..7198314 100644 --- a/debian/ifup@.service +++ b/debian/ifup@.service @@ -3,6 +3,7 @@ Description=ifup for %I After=local-fs.target networking.service Before=network.target BindsTo=sys-subsystem-net-devices-%i.device +ConditionPathIsDirectory=/run/network DefaultDependencies=no [Service] -- 2.1.3 ___ 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#768456: init-system-helpers: deb-system-invoke starts disabled systemd service on package upgrade
Package: init-system-helpers Version: 1.21 Severity: normal Dear Maintainer, deb-system-invoke starts disabled systemd services (and so, in case of systemd only services), when there is no init script. As discuss on #debian-systemd, we can add some conditions to start the job on deb-system-invoke [restart|start], during package upgrade: - deb-system-invoke start unit don't do anything on systemd if the service is disabled. - deb-system-invoke restart unit only restart a disabled service if if the daemon was already running (forced by the admin). -- System Information: Debian Release: jessie/sid APT prefers vivid-updates APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-24-generic (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages init-system-helpers depends on: ii perl 5.20.1-2 init-system-helpers recommends no packages. init-system-helpers 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
Bug#768456: Patch
Please find the attached debdiff trying to address the issue.
Any suggestion to enhance it is welcome. :)
diff -Nru init-system-helpers-1.21/debian/changelog
init-system-helpers-1.22/debian/changelog
--- init-system-helpers-1.21/debian/changelog 2014-08-21 07:40:58.0
+0200
+++ init-system-helpers-1.22/debian/changelog 2014-11-07 15:13:08.0
+0100
@@ -1,3 +1,16 @@
+init-system-helpers (1.22) UNRELEASED; urgency=medium
+
+ * deb-system-invoke: don't start disabled systemd services (in case
+of systemd only services), when there is no init script.
+Add some conditions to start the job on deb-system-invoke [restart|start],
+during package upgrade: (Closes: #768456)
+- deb-system-invoke start unit don't do anything on systemd if the
+ service is disabled.
+- deb-system-invoke restart unit only restart a disabled service if
+ if the daemon was already running (forced by the admin).
+
+ -- Didier Roche didro...@ubuntu.com Fri, 07 Nov 2014 15:01:27 +0100
+
init-system-helpers (1.21) unstable; urgency=medium
* Demote augeas-tools to Suggests and let the systemd2init tool error out
diff -Nru init-system-helpers-1.21/script/deb-systemd-invoke
init-system-helpers-1.22/script/deb-systemd-invoke
--- init-system-helpers-1.21/script/deb-systemd-invoke 2014-08-21
07:40:58.0 +0200
+++ init-system-helpers-1.22/script/deb-systemd-invoke 2014-11-07
15:01:24.0 +0100
@@ -77,4 +77,21 @@
}
}
-exec '/bin/systemctl', @ARGV;
+# If the job is disabled and is not currently running, the job is not started
or restarted.
+# However, if the job is disabled but has been forced into the running state,
we *do* stop
+# and restart it since this is expected behaviour for the admin who forced the
start.
+if (grep(/^$action$/, [start, restart])) {
+for my $unit (@units) {
+my $job_status = `/bin/systemctl status $unit`;
+if (($job_status =~ /disabled/) ($action eq start)) {
+print STDERR $unit is disabled, don't start it.\n;
+exit 0;
+} elsif (($job_status =~ /disabled/) ($job_status !~ /running/)
($action eq restart)) {
+print STDERR $unit is disabled and not running, don't start
it.\n;
+exit 0;
+}
+exec '/bin/systemctl', $action, $unit;
+}
+} else {
+exec '/bin/systemctl', @ARGV;
+}
___
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#768456: Second version of the patch
Here is a second version of the patch after feedback on OFTC. It uses
more robust commands then parsing the status output.
Note that I don't use try-restart as it doesn't map the case of job
enabled but stopped - restart on package upgrade is supposed to start
the daemon (as with init case).
Do not hesitate if you see any other needed changes.
diff -Nru init-system-helpers-1.21/debian/changelog
init-system-helpers-1.22/debian/changelog
--- init-system-helpers-1.21/debian/changelog 2014-08-21 07:40:58.0
+0200
+++ init-system-helpers-1.22/debian/changelog 2014-11-07 15:13:08.0
+0100
@@ -1,3 +1,16 @@
+init-system-helpers (1.22) UNRELEASED; urgency=medium
+
+ * deb-system-invoke: don't start disabled systemd services (in case
+of systemd only services), when there is no init script.
+Add some conditions to start the job on deb-system-invoke [restart|start],
+during package upgrade: (Closes: #768456)
+- deb-system-invoke start unit don't do anything on systemd if the
+ service is disabled.
+- deb-system-invoke restart unit only restart a disabled service if
+ if the daemon was already running (forced by the admin).
+
+ -- Didier Roche didro...@ubuntu.com Fri, 07 Nov 2014 15:01:27 +0100
+
init-system-helpers (1.21) unstable; urgency=medium
* Demote augeas-tools to Suggests and let the systemd2init tool error out
diff -Nru init-system-helpers-1.21/script/deb-systemd-invoke
init-system-helpers-1.22/script/deb-systemd-invoke
--- init-system-helpers-1.21/script/deb-systemd-invoke 2014-08-21
07:40:58.0 +0200
+++ init-system-helpers-1.22/script/deb-systemd-invoke 2014-11-07
16:10:39.0 +0100
@@ -77,4 +77,24 @@
}
}
-exec '/bin/systemctl', @ARGV;
+# If the job is disabled and is not currently running, the job is not started
or restarted.
+# However, if the job is disabled but has been forced into the running state,
we *do* stop
+# and restart it since this is expected behaviour for the admin who forced the
start.
+if (grep(/^$action$/, [start, restart])) {
+for my $unit (@units) {
+system(systemctl --quiet is-enabled $unit);
+my $unit_enabled = $?8;
+system(systemctl --quiet is-active $unit);
+my $unit_active = $?8;
+if (($unit_enabled != 0) ($action eq start)) {
+print STDERR $unit is disabled, don't start it.\n;
+} elsif (($unit_enabled != 0) ($unit_active != 0) ($action eq
restart)) {
+print STDERR $unit is disabled and not running, don't start
it.\n;
+}
+else {
+system('/bin/systemctl', $action, $unit);
+}
+}
+} else {
+exec '/bin/systemctl', @ARGV;
+}
___
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#768456: Version 3 including ansgar's and pitti's feedback
Here is the v3 of the patch, which includes ansgar's and pitti's
feedback. Thanks to them!
The only suggestion I couldn't integrate is Martin's system vs exec one.
I had to change keep it as system() call as we are evaluating one unit
after another as the scripts can accepts multiple units, and so exec
would prefer the evaluation and inclusion of other units passed as
parameters.
Does this make sense? The downside is that we loose the return code,
indeed (we could concatenate it if needed).
Cheers,
Didier
diff -Nru init-system-helpers-1.21/debian/changelog
init-system-helpers-1.22/debian/changelog
--- init-system-helpers-1.21/debian/changelog 2014-08-21 07:40:58.0
+0200
+++ init-system-helpers-1.22/debian/changelog 2014-11-07 15:13:08.0
+0100
@@ -1,3 +1,16 @@
+init-system-helpers (1.22) UNRELEASED; urgency=medium
+
+ * deb-system-invoke: don't start disabled systemd services (in case
+of systemd only services), when there is no init script.
+Add some conditions to start the job on deb-system-invoke [restart|start],
+during package upgrade: (Closes: #768456)
+- deb-system-invoke start unit don't do anything on systemd if the
+ service is disabled.
+- deb-system-invoke restart unit only restart a disabled service if
+ if the daemon was already running (forced by the admin).
+
+ -- Didier Roche didro...@ubuntu.com Fri, 07 Nov 2014 15:01:27 +0100
+
init-system-helpers (1.21) unstable; urgency=medium
* Demote augeas-tools to Suggests and let the systemd2init tool error out
diff -Nru init-system-helpers-1.21/script/deb-systemd-invoke
init-system-helpers-1.22/script/deb-systemd-invoke
--- init-system-helpers-1.21/script/deb-systemd-invoke 2014-08-21
07:40:58.0 +0200
+++ init-system-helpers-1.22/script/deb-systemd-invoke 2014-11-07
17:08:10.0 +0100
@@ -77,4 +77,24 @@
}
}
-exec '/bin/systemctl', @ARGV;
+# If the job is disabled and is not currently running, the job is not started
or restarted.
+# However, if the job is disabled but has been forced into the running state,
we *do* stop
+# and restart it since this is expected behaviour for the admin who forced the
start.
+if ($action eq start || $action eq restart) {
+for my $unit (@units) {
+system('/bin/systemctl', '--quiet', 'is-enabled', '--', $unit);
+my $unit_enabled = $?8 == 0 ? 1 : 0;
+system('/bin/systemctl', '--quiet', 'is-active', '--', $unit);
+my $unit_active = $?8 == 0 ? 1 : 0;
+if (!$unit_enabled $action eq start) {
+print STDERR $unit is disabled, not starting it.\n;
+} elsif (!$unit_enabled !$unit_active $action eq restart) {
+print STDERR $unit is disabled and not running, not starting
it.\n;
+}
+else {
+system('/bin/systemctl', $action, $unit);
+}
+}
+} else {
+exec '/bin/systemctl', @ARGV;
+}
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
