Bug#999695: systemd: emergency/rescue targets fail to stop journald
Am 28.11.21 um 12:37 schrieb westlake: On 2021-11-15 10:10 a.m., Michael Biebl wrote: I think, what you see is that systemd-journald.service *is* actually stopped when you run `systemctl emergency`. systemctl isolate emergency and systemctl emergency have the same results unfortunately.. Could you check the following: - When you enter the emergency shell, check the journal if systemd-journald.service has been stopped (and started again) - If any of the above sockets are active? they're all active... systemd-journald.socket systemd-journald-dev-log.socket, and systemd-audit.socket while in emergency.. I can only report against the latest two versions of systemd to github upstream. was told so, over here, https://github.com/systemd/systemd/issues/21370 I tried to report upstream as much as possible in general, but with the systemd project --- the upstream requires very recent builds --- which debian doesn't have any... so I can't report my bugs upstream at that location. That's not correct, btw. The Debian project provides the latest systemd versions via stable backports. See https://packages.debian.org/source/stable-backports/systemd (We currently lack by one revision due to the ongoing openssl3 transition). instead I am told by their lead developer to file things over here. I also would like that other issue(I pasted url above), to be fixed as well... are you going to tell me to report that upstream as well? Mister Lennard Poettering is blaming broken debian md-raid packages --- which Fwiw, his name is Lennart. is 100% not true at all.. it's just that he doesn't want to bother for "older" systemd builds... I am 100% sure he could of looked more into it, but he doesn't want to.. Reading through the above mentioned github issue, Lennart was right. You (accidentally) broke your system by masking the tmp.mount unit and his advice was correct. If you want to override a tmp.mount unit via /etc/fstab, simply add an entry for /tmp there. This will generate a tmp.mount unit in /run/systemd/system which will take precedence over any tmp.mount unit shipped in /lib/systemd/system See man systemd.unit about the order of "System Unit Search Path" and man systemd-fstab-generator. If you used a custom tmp.mount unit in /etc/systemd/system and want to use /etc/fstab instead, remove /etc/systemd/system/tmp.mount. Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#999695: systemd: emergency/rescue targets fail to stop journald
On 28.11.21 12:37, westlake wrote: FIX IT NOW!! Please dial down your rhetoric a couple of notches. All it has achieved so far is that I'm no longer motivated to look at this issue. OpenPGP_signature Description: OpenPGP digital signature
Bug#999695: systemd: emergency/rescue targets fail to stop journald
On 2021-11-15 10:10 a.m., Michael Biebl wrote: I think, what you see is that systemd-journald.service *is* actually stopped when you run `systemctl emergency`. systemctl isolate emergency and systemctl emergency have the same results unfortunately.. Could you check the following: - When you enter the emergency shell, check the journal if systemd-journald.service has been stopped (and started again) - If any of the above sockets are active? they're all active... systemd-journald.socket systemd-journald-dev-log.socket, and systemd-audit.socket while in emergency.. I can only report against the latest two versions of systemd to github upstream. was told so, over here, https://github.com/systemd/systemd/issues/21370 I tried to report upstream as much as possible in general, but with the systemd project --- the upstream requires very recent builds --- which debian doesn't have any... so I can't report my bugs upstream at that location. instead I am told by their lead developer to file things over here. I also would like that other issue(I pasted url above), to be fixed as well... are you going to tell me to report that upstream as well? Mister Lennard Poettering is blaming broken debian md-raid packages --- which is 100% not true at all.. it's just that he doesn't want to bother for "older" systemd builds... I am 100% sure he could of looked more into it, but he doesn't want to.. so fix it please. FIX IT NOW!! THANKS!
Bug#999695: systemd: emergency/rescue targets fail to stop journald
Am 15.11.21 um 03:44 schrieb westlake: Upon booting up with "systemd.unit=emergency.target" to the kernel bootline, there are no systemd-journald services running. I'd say this is expected, as sockets.target is not started. See below However if the user boots normally into multi-user or graphical targets, and types "systemctl isolate emergency" or "systemctl emergency", debian does not stop systemd-journald services. I think, what you see is that systemd-journald.service *is* actually stopped when you run `systemctl emergency`. But systemd-journald.service is socket activated. So there might be a race condition or a problem with the corresponding systemd-journald sockets: $ systemctl show -P TriggeredBy systemd-journald.service systemd-journald-audit.socket systemd-journald-dev-log.socket systemd-journald.socket Could you check the following: - When you enter the emergency shell, check the journal if systemd-journald.service has been stopped (and started again) - If any of the above sockets are active? In any case, this doesn't appear to be a Debian specific issue, so I would kindly ask you to file this upstream at https://github.com/systemd/systemd and report back with the issue number. Regards, Michael
Bug#999695: systemd: emergency/rescue targets fail to stop journald
Package: systemd Version: 247.3-6 Severity: normal Upon booting up with "systemd.unit=emergency.target" to the kernel bootline, there are no systemd-journald services running. However if the user boots normally into multi-user or graphical targets, and types "systemctl isolate emergency" or "systemctl emergency", debian does not stop systemd-journald services. this is a problem noticeably if the user wants to perform work on "/" with "mount -o ro,remount /". please fix this thanks scott
