Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start
On 8 August 2016 at 10:03, Felipe Sateler wrote: > On 8 August 2016 at 02:59, Pete Batard wrote: >> Thanks Felipe. >> >> I'm afraid it's still not completing successfully though: > > Gah, I'm terribly sorry. I have a fix here, but I'm testbuilding first > before asking you to do that again. I'll let you know as soon as I > have built it. It has built fine. You can grab it again from https://people.debian.org/~fsateler/systemd/ . This time I have prebuilt armhf binaries so you can skip the build part :) -- Saludos, Felipe Sateler ___ 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#833849: systemd: localed fails to start if /etc/default/keyboard is missing
Processing control commands: > tags -1 pending Bug #833849 [systemd] systemd: localed fails to start if /etc/default/keyboard is missing Added tag(s) pending. -- 833849: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833849 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#833849: systemd: localed fails to start if /etc/default/keyboard is missing
Control: tags -1 pending On 9 August 2016 at 08:07, Simon McVittie wrote: > > Package: systemd > Version: 231-1 > Severity: normal > Tags: patch > > I'm using systemd on an embedded Debian derivative that doesn't routinely > populate /etc/default/keyboard (our target devices don't normally have > keyboards, so it would be meaningless). On this system, localed doesn't > start when activated via D-Bus: > > systemd-localed[9146]: Failed to read locale data: No such file or > directory > > This appears to be because the upstream code to load a Red Hat-specific > X11 keyboard configuration file tolerates it not existing, but the > Debian patch to load /etc/default/keyboard instead does not tolerate > ENOENT. > > To fix this, I applied the patch > 0001-x11_read_data-tolerate-absence-of-etc-default-keyboa.patch > (this is a forward-port to 231, the one I initially used was for an > earlier systemd version and touched the same code in a different file) > just after Use-Debian-specific-config-files.patch in the patch > series, then squashed it into that commit to get the attached > 0001-Use-Debian-specific-config-files.patch (again, this is a > forward-port). > > I'm not attaching a proposed debdiff because the resulting diff between > diffs is basically impossible to review :-) Thanks for the patch.This makes a lot of sense, especially because ENOENT is tolerated everywhere in that file. I have applied this to git with the following commit message attributed to you: localed: tolerate absence of /etc/default/keyboard The debian-specific patch to read Debian config files was not tolerating the absence of /etc/default/keyboard. This causes systemd-localed to fail to start on systems where that file isn't populated (like embedded systems without keyboards). Closes: #833849 -- Saludos, Felipe Sateler ___ 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#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start
On 12 August 2016 at 11:05, Pete Batard wrote: > Thanks Felipe. > > I installed libsystemd0_231-2_armhf.deb but shouldn't there be a > systemd_231-2_armhf.deb as well? Strangely there's a > systemd-dbgsym_231-2_armhf.deb but no non-dbgsym version, as opposed to > other .debs. Sorry about that. Somehow that deb didn't get uploaded from my machine. > The .dsc does mention a 'systemd' binary, and earlier, the idea was to > install 'libsystemd0' and 'systemd' from the generated debs. > > For the time being, I'm not sure if I should just go ahead and install the > dbgsym version, or if there's still one piece missing. > > Please let me know before I proceed. No, the -dbgsym version only contains debugging symbols, not the actual executables. -- Saludos, Felipe Sateler ___ 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#833849: systemd: localed fails to start if /etc/default/keyboard is missing
On Fri, 12 Aug 2016 11:16:25 -0300 Felipe Sateler wrote: > Thanks for the patch.This makes a lot of sense, especially because > ENOENT is tolerated everywhere in that file. I have applied this to > git with the following commit message attributed to you: > > localed: tolerate absence of /etc/default/keyboard > > The debian-specific patch to read Debian config files was not tolerating > the absence of /etc/default/keyboard. This causes systemd-localed to > fail to start on systems where that file isn't populated (like embedded > systems without keyboards). > > Closes: #833849 I ran into the same bug on Debian testing with 215-17+deb8u4. Can we get the fix also into jessie? -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 D - 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: http://www.profitbricks.com Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 125506B. Geschäftsführer: Andreas Gauger, Achim Weiss. ___ 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#834164: systemd: Services are not killed after a timeout or killed immediately after ExecStop
Package: systemd Version: 215-17+deb8u4 Severity: normal I am trying to set up a service shutdown sequence in a way that the service is asked nicely to quit, and if it doesn't, then it's killed after a timeout. Sounds very simple - this is very basic. According to man systemd.service, TimeoutStopSec= Configures the time to wait for stop. If a service is asked to stop, but does not terminate in the specified time, it will be terminated forcibly via SIGTERM, and after another timeout of equal duration with SIGKILL (see KillMode= in systemd.kill(5)). However, with this setup: ExecStop= KillMode=none TimeoutStopSec=10s the service is NEVER killed - even after 10s timeout. Maybe I don't understand what's written in the manual? I just can't believe such a basic thing could seriously be overlooked up until now... I've also tried the same with KillMode=process (and without KillMode at all - it defaults to control-group), hoping that maybe it will give my service some time to shut down after ExecStop=, but it killed the process immediately (and it went into "failed" mode for not stopping quickly enough). Why do we have ExecStop= at all if the service is killed immediately anyway? This behaviour us the same in a newer version of systemd in Linux Mint 18, so it's an upstream bug. (Either that, or I really don't understand something that simple.) Here is a sample .service file that can be used safely to test this behaviour. = = = = = = = test.service = = = = = = = [Unit] Description=Test service [Service] ExecStart=/usr/bin/screen -h 1024 -dmS test ftp nonExistentServer Type=forking ExecStop=/usr/bin/screen -p 0 -S test -X eval 'stuff \"ServiceGoDie\"\015' # Change the command to "bye" to actually let the "service" quit # Otherwise it is supposed to fail to quit peacefully # and be killed after 10s after "systemctl stop test" KillMode=none TimeoutStopSec=10s [Install] WantedBy=multi-user.target = = = = = = = -- Package-specific info: -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.18-aufs (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-59 ii libacl1 2.2.52-2 ii libaudit1 1:2.4-1+b1 ii libblkid1 2.25.2-6 ii libc6 2.19-18+deb8u4 ii libcap2 1:2.24-8 ii libcap2-bin 1:2.24-8 ii libcryptsetup4 2:1.6.6-5 ii libgcrypt20 1.6.3-2+deb8u1 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2+b3 ii libpam0g1.1.8-3.1+deb8u1+b1 ii libselinux1 2.3-2 ii libsystemd0 215-17+deb8u4 ii mount 2.25.2-6 ii sysv-rc 2.88dsf-59 ii udev215-17+deb8u4 ii util-linux 2.25.2-6 Versions of packages systemd recommends: ii dbus1.8.20-0+deb8u1 ii libpam-systemd 215-17+deb8u4 Versions of packages systemd suggests: pn systemd-ui -- no debconf information -- darkpenguin ___ 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#834164: marked as done (systemd: Services are not killed after a timeout or killed immediately after ExecStop)
Your message dated Fri, 12 Aug 2016 16:48:50 -0300 with message-id and subject line Re: Bug#834164: systemd: Services are not killed after a timeout or killed immediately after ExecStop has caused the Debian Bug report #834164, regarding systemd: Services are not killed after a timeout or killed immediately after ExecStop to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 834164: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834164 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd Version: 215-17+deb8u4 Severity: normal I am trying to set up a service shutdown sequence in a way that the service is asked nicely to quit, and if it doesn't, then it's killed after a timeout. Sounds very simple - this is very basic. According to man systemd.service, TimeoutStopSec= Configures the time to wait for stop. If a service is asked to stop, but does not terminate in the specified time, it will be terminated forcibly via SIGTERM, and after another timeout of equal duration with SIGKILL (see KillMode= in systemd.kill(5)). However, with this setup: ExecStop= KillMode=none TimeoutStopSec=10s the service is NEVER killed - even after 10s timeout. Maybe I don't understand what's written in the manual? I just can't believe such a basic thing could seriously be overlooked up until now... I've also tried the same with KillMode=process (and without KillMode at all - it defaults to control-group), hoping that maybe it will give my service some time to shut down after ExecStop=, but it killed the process immediately (and it went into "failed" mode for not stopping quickly enough). Why do we have ExecStop= at all if the service is killed immediately anyway? This behaviour us the same in a newer version of systemd in Linux Mint 18, so it's an upstream bug. (Either that, or I really don't understand something that simple.) Here is a sample .service file that can be used safely to test this behaviour. = = = = = = = test.service = = = = = = = [Unit] Description=Test service [Service] ExecStart=/usr/bin/screen -h 1024 -dmS test ftp nonExistentServer Type=forking ExecStop=/usr/bin/screen -p 0 -S test -X eval 'stuff \"ServiceGoDie\"\015' # Change the command to "bye" to actually let the "service" quit # Otherwise it is supposed to fail to quit peacefully # and be killed after 10s after "systemctl stop test" KillMode=none TimeoutStopSec=10s [Install] WantedBy=multi-user.target = = = = = = = -- Package-specific info: -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.18-aufs (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-59 ii libacl1 2.2.52-2 ii libaudit1 1:2.4-1+b1 ii libblkid1 2.25.2-6 ii libc6 2.19-18+deb8u4 ii libcap2 1:2.24-8 ii libcap2-bin 1:2.24-8 ii libcryptsetup4 2:1.6.6-5 ii libgcrypt20 1.6.3-2+deb8u1 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2+b3 ii libpam0g1.1.8-3.1+deb8u1+b1 ii libselinux1 2.3-2 ii libsystemd0 215-17+deb8u4 ii mount 2.25.2-6 ii sysv-rc 2.88dsf-59 ii udev215-17+deb8u4 ii util-linux 2.25.2-6 Versions of packages systemd recommends: ii dbus1.8.20-0+deb8u1 ii libpam-systemd 215-17+deb8u4 Versions of packages systemd suggests: pn systemd-ui -- no debconf information -- darkpenguin --- End Message --- --- Begin Message --- On 12 August 2016 at 12:26, Dark Penguin wrote: > Package: systemd > Version: 215-17+deb8u4 > Severity: normal > > > I am trying to set up a service shutdown sequence in a way that the service > is asked nicely to quit, and if it doesn't, then it's killed after a > timeout. Sounds very simple - this is very basic. > > According to man systemd.service, > > TimeoutStopSec= > Configures the time to wait for stop. If a service is asked to > stop, but does not terminate in the specified time, it will be > terminated forcibly via SIGTERM, and after another timeout of equal > duration with SIGKILL (see KillMode= in systemd.kill(5)). > > However, with this setup: > > ExecStop= >From the manpage: After the commands configured in this option are run, a
Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start
On Aug 12, 2016, at 9:21 AM, Pete Batard wrote: > Okay. I have now gone through a dpkg -i install of all the (non dbgsym) .deb > I see on your server, and also issued a reboot for good measure, but I still > see the same problem with journald being failed, along with dependent services Hi Filipe, Would you like me to also do what pete describes (all the .deb files) or is there a more fine-grained test you’d like me to try? Rick ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
