Bug#858162: /bin/systemctl: systemctl rescue hangs system cold if desktop session is active
On Mon, Mar 20, 2017 at 01:38:49AM +0100, Michael Biebl wrote: > Am 20.03.2017 um 01:36 schrieb Michael Biebl: > > The relevant bits are in the journal log > >> Mar 19 20:09:08 stretch systemd[1]: Stopped Login Service. > > > Some of those in between > > Mar 19 20:09:08 stretch dbus[451]: [system] Activation via systemd failed > > for unit 'dbus-org.freedesktop.login1.service': Refusing activation, D-Bus > > is shutting down. > > Mar 19 20:09:08 stretch /usr/lib/gdm3/gdm-x-session[970]: (EE) > > systemd-logind: failed to release device: Refusing activation, D-Bus is > > shutting down. > > > > >> Mar 19 20:09:08 stretch /usr/lib/gdm3/gdm-x-session[970]: (II) > >> systemd-logind: releasing fd for 13:69 > >> Mar 19 20:09:08 stretch /usr/lib/gdm3/gdm-x-session[970]: (EE) > >> systemd-logind: failed to release device: Connection was disconnected > >> before a reply was received > >> Mar 19 20:09:08 stretch /usr/lib/gdm3/gdm-x-session[970]: (II) > >> UnloadModule: "libinput" > >> Mar 19 20:09:08 stretch /usr/lib/gdm3/gdm-x-session[970]: (II) > >> systemd-logind: releasing fd for 13:67 > >> Mar 19 20:09:08 stretch /usr/lib/gdm3/gdm-x-session[970]: (EE) > >> systemd-logind: failed to release device: Connection is closed > >> Mar 19 20:09:08 stretch /usr/lib/gdm3/gdm-x-session[970]: (WW) > >> xf86CloseConsole: KDSETMODE failed: Input/output error > >> Mar 19 20:09:08 stretch /usr/lib/gdm3/gdm-x-session[970]: (WW) > >> xf86CloseConsole: VT_GETMODE failed: Input/output error > >> Mar 19 20:09:08 stretch /usr/lib/gdm3/gdm-x-session[970]: (WW) > >> xf86CloseConsole: VT_ACTIVATE failed: Input/output error > >> Mar 19 20:09:08 stretch /usr/lib/gdm3/gdm-x-session[970]: (EE) > >> systemd-logind: ReleaseControl failed: Connection is closed Attached is the log from the unresponsive rescue prompt (as opposed to dead X desktop). The 4 xf86CloseConsole lines aren't there, but the other stuff looks mostly the same. Sorry for the previous mangled text. That's what I get for posting from gmail... -nd. systemd-init1-logs2.txt.gz Description: application/gzip ___ 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#858211: systemd: uninterruptible wait if swap is missing, even in rescue boot
On Sun, Mar 19, 2017 at 09:53:58PM +0100, Michael Biebl wrote: > Since systemd starts everything in parallel, which service should > ctrl+c apply to? In this situation, systemd gives the distinct impression that all other jobs have started, and it is now waiting for just one. A countdown timer is displayed (screenshot attached). So I don't think there's any doubt as to what the user *expects* ^C to do here: interrupt the wait. As a minor aside, I've also attached a screenshot of the same situation on a jessie system, the difference being that stretch clears the screen right before. Is that intentional, or worth filing another bug over? > What you want is emergency.target for a case like yours. > > Add "emergency" or systemd.unit=emergency.target to the kernel command > line for that. This works great, thank you. > It waits for the device to show up. A heuristic which concludes from the > device name whether a device still can show up or not sounds very > brittle to me and thus not a good idea. Yeah, you're right. The ideal behavior IMO would be to display what is happening (already done, and rather nicely) and allow the user/operator to choose whether or not to wait. Since legacy init allowed this via ^C, it even seems like a reasonable expectation. For me personally, reducing this timeout to 3 seconds instead of 90 would seem to be a decent workaround, along with the emergency target. That being said, I still think I have a valid wishlist item here, at the very least. As things stand now, is the 90 seconds really a sane default? I can imagine some cases in which it'd be better than 3, but none of them seem typical. The same thing applies to shutdown; a database server might need that long to shut down, but waiting more than 15 or so for any old process seems like a waste of time. > For missing swap devices it does not drop you into rescue mode. Missing > file systems on the other hand will trigger rescue mode. I assume this > is a reasonable choice. > > The error will show up in the journal, fwiw. That's fair enough. Personally, I think an aborted boot would be better than being surprised by missing swap in the (unlikely) event it's actually needed. I assume I could change this, though, if I actually cared to. Thanks again, -nd. ___ 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#858211: (no subject)
Just to confirm, things seem OK with the following in system.conf: DefaultTimeoutStartSec=3s DefaultTimeoutStopSec=15s Everything including graphical desktop login comes up and down with no issues. I think it'd be slightly better to keep the longer timeout, but allow the console operator to interrupt it. Hopefully, I got the Control headers right to make this a wishlist. ___ 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#837893: systemd: Logging from gnome session is passed on to all syslog facilities
I think these messages are being (erroneously) passed specifically to
the KERN facility, not all facilities as the summary states.
For one thing, the superfluous messages don't appear in the user.log
file, as they do in kern.log, despite the fact that rsyslogd is
configured to route all facility=USER messages there, as per the
Debian default:
root@stretch:/var/log# fgrep -c 'Mar 25 21:07:16 stretch NetworkManager[423]:
[1490497636.9242] manager: startup complete' kern.log syslog user.log
kern.log:1
syslog:1
user.log:0
root@stretch:/var/log# egrep '(user|kern).log' /etc/rsyslog.conf
kern.* -/var/log/kern.log
user.* -/var/log/user.log
root@stretch:/var/log#
For another, after configuring rsyslogd with a custom template that
includes the facility (and priority) with each message, the offending
messages consistently have facility=KERN in every file in which they
do appear:
root@stretch:/var/log# fgrep template /etc/rsyslog.conf
$template MyFormat,"%pri-text%: %timegenerated% %HOSTNAME%
%syslogtag%%msg:::drop-last-lf%\n"
root@stretch:/var/log# fgrep -R 'Mar 25 21:35:19 stretch NetworkManager[423]:
[1490499319.1248] device (ens3): Activation: successful, device
activated.'
messages:kern.info: Mar 25 21:35:19 stretch NetworkManager[423]:
[1490499319.1248] device (ens3): Activation: successful, device activated.
kern.log:kern.info: Mar 25 21:35:19 stretch NetworkManager[423]:
[1490499319.1248] device (ens3): Activation: successful, device activated.
syslog:kern.info: Mar 25 21:35:19 stretch NetworkManager[423]:
[1490499319.1248] device (ens3): Activation: successful, device activated.
root@stretch:/var/log#
I'll go on the record with a prediction that this will turn out to be
directly related to the fact that the numeric value representing the
KERN facility is zero:
root@stretch:/var/log# fgrep KERN /usr/include/*/sys/syslog.h
#define LOG_KERN(0<<3) /* kernel messages */
{ "kern", LOG_KERN },
root@stretch:/var/log#
Anyway, this problem also exists on jessie, with systemd 215.
NetworkManager doesn't exhibit the problem there, making it less
noticeable, but gnome-session and pulseaudio can be seen in the
kern.log file.
One acceptable workaround seems to be to just disable the broken
functionality altogether, with ForwardToSyslog=no in
/etc/systemd/journald.conf, and just use journalctl(1) to view those
messages. Note, however, that the journal is only stored under /run by
default and so will be lost on shutdown; to avoid that, you simply
have to create the default directory /var/log/journal, and it will be
persisted there.
-nd.
___
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#854699: systemd: Errors at shutdown after fresh LUKS+LVM stretch install
On Wed, Mar 29, 2017 at 06:35:35AM +0200, Michael Biebl wrote: > Am 29.03.2017 um 06:03 schrieb Nathan Dorfman: > > Package: systemd > > Version: 232-19 > > Followup-For: Bug #848044 > > > > Just tried a fresh install using the stretch rc2 amd64 netinst ISO, > > and the guided/entire-disk LVM+LUKS install option. > > > > There's no delay at shutdown, but there are errors about stopping > > dm-crypt and LVM; see attached screenshot. These consistently > > occur at every shutdown, and so far, seem harmless. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854699 Thanks, Michael. I tried your test packages, and the first thing I noticed is that the shutdown messages are no longer visible; instead, I see some corrupted fragments of the startup messages (screenshot attached). The system still rebooted after a couple of seconds as expected, though. Anyway, I'm running with the persistent journal enabled, so I was able to look at journalctl -ab-1. Most of the errors are gone, but the final error, about systemd-cryptsetup@vda5_crypt.service, remains. Strangely, I see no mention of any kind of fsck of / in any of the journals -- might you happen to know why that would be, or how I can verify whether or not it was found to be clean? (I see the fscheck for /boot, on /dev/vda1, but not / on /dev/mapper/stretch--vg-root.) I've attached the full output of journalctl -ab-1, which is with your test packages, as well as the same from the last boot without them. To summarize, these are the errors that are no longer present with your changes: Mar 28 23:20:39 stretch systemd[1]: Stopped Create Volatile Files and Directories. Mar 28 23:20:39 stretch systemd[1]: Reloading. Mar 28 23:20:39 stretch systemd[1]: Stopped (with error) /dev/disk/by-id/dm-name-vda5_c rypt. Mar 28 23:20:39 stretch systemd[1]: Stopped (with error) /dev/disk/by-id/dm-uuid-CRYPT- LUKS1-f96f4a3e07a84aa48123d83ba6c24f53-vda5_crypt. Mar 28 23:20:39 stretch systemd[1]: Stopped (with error) /sys/devices/virtual/block/dm- 0. Mar 28 23:20:39 stretch systemd[1]: Stopped (with error) /dev/dm-0. Mar 28 23:20:39 stretch systemd[1]: Stopped (with error) /dev/mapper/vda5_crypt. Mar 28 23:20:39 stretch systemd[1]: Stopped (with error) /dev/disk/by-id/lvm-pv-uuid-ozNpTU-66St-dPt6-SXcq-BDtH-hwD1-hFXNvD. Mar 28 23:20:39 stretch systemd[1]: Stopped Raise network interfaces. And these are the ones that still are: Mar 28 23:49:59 stretch systemd[1]: Stopping LVM2 metadata daemon... Mar 28 23:49:59 stretch lvmetad[287]: Failed to accept connection errno 11. Mar 28 23:49:59 stretch systemd[1]: Stopped LVM2 metadata daemon. Mar 28 23:50:04 stretch systemd-cryptsetup[1075]: Failed to deactivate: Device or resource busy Mar 28 23:50:04 stretch systemd[1]: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited status=1 Mar 28 23:50:04 stretch systemd[1]: Stopped Cryptography Setup for vda5_crypt. Mar 28 23:50:04 stretch systemd[1]: systemd-cryptsetup@vda5_crypt.service: Unit entered failed state. Mar 28 23:50:04 stretch systemd[1]: systemd-cryptsetup@vda5_crypt.service: Failed with result 'exit-code'. Mar 28 23:50:04 stretch systemd[1]: Reached target Unmount All Filesystems. -nd. journalctl-ab-1_testpkgs.txt.gz Description: application/gzip journalctl-ab-6_unmodified.txt.gz Description: application/gzip ___ 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#802211: systemd: rescue.service fails if root password is not set, needs sulogin --force
Hi, this is still an issue with the default stretch install, if the option to not set a root password is taken at installation. It is quite severe IMO, especially considering how likely it is to be discovered only when the rescue shell is actually needed. If this really can't be fixed before release, I'd strongly suggest that debian-installer force a root password to be set until it can. On a secondary note, I personally find it rather ludicrous that this trivial fix is being held up by some kiosk considerations. Setting up one of those usually requires many other customizations (for example, disabling the default window manager), and it makes little sense to opt for sudo over a separate root account at installation time for a kiosk in the first place. On the other hand, the much more common desktop use case shouldn't be this broken out of the box. IMHO, of course. -nd. ___ 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#802211: systemd: rescue.service fails if root password is not set, needs sulogin --force
On Fri, Mar 31, 2017 at 12:51:08AM +0200, Michael Biebl wrote: > Maybe I'm overly paranoid here, but maybe that helps to better > understand my concerns. No, your concerns sound reasonable to me, and I agree that demanding a username from group sudo, along with its password sounds like it could be even better. However, I think it might not be necessary. Simply warn the user what is going to happen if they don't set the root password at install time: rescue boot will be left unprotected. Some users might prefer that behavior anyway -- as someone pointed out, the rescue shell would still work even if passwd/shadow are lost. Users that are setting up BIOS and grub passwords can be expected to set the root password as well, IMHO. Obviously, the installer should make it unmistakably clear. If that's not acceptable, I hope you'll agree that the installer should just force you to set a root password. It's not reasonable for it to quietly leave you with a rescue shell that won't work at all. However, I honestly think the more lenient solution is better: an empty root password usable only at rescue boot seems preferable to a very weak password that could be allowed elsewhere. That said, I just noticed that we seem to have PermitRootLogin prohibit-password in sshd_config by default now, so this might be a minor or even moot point. -nd. ___ 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#859189: systemd-logind: Unix group changes ignored by gdm/lightdm until logind is restarted
Control: retitle -1 systemd-logind: Unix group changes ignored by gdm/lightdm until logind is restarted On Fri, Mar 31, 2017 at 12:40:55PM +0200, Michael Biebl wrote: > When you log out, do you still have an open logind session for that user > (you can check that as root from the console via loginctl) Hmm, yes. It looks like they never go away; after logging out and back in a few times, I have this: SESSIONUID USER SEAT TTY 8 1000 test seat0 10 1000 test seat0/dev/tty2 6 1000 test seat0 11 1000 test seat0 c5117 lightdm seat0 2 1000 test seat0 6 sessions listed. All the sessions except 10 and c5 are X logins that are no longer active. (Session 10, on tty2, was opened after all this, just so I could run loginctl.) On Fri, Mar 31, 2017 at 12:41:42PM +0200, Michael Biebl wrote: > Are you using gnome-terminal? > What if you use xterm? Well, that was totally unexpected! It only happens in gnome-terminal, not xterm, rxvt or xfce4-terminal. It didn't even occur to me that it'd do anything other than inherit its GID set from the X session, (without any kind of --login option, that is). Anyway, it also continues to assign me groups that no longer exist. After deleting them with groupdel(1) and logging out and back in: test@stretch:~$ groups test cdrom floppy sudo audio dip video plugdev netdev bluetooth scanner groups: cannot find name for group ID 1001 1001 groups: cannot find name for group ID 1002 1002 test@stretch:~$ BTW, is it correct to Cc you on all of these? Or should I only send them to the bug? -nd. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
