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
Am 15.11.21 um 03:44 schrieb westlake: I'd say this is expected, as sockets.target is not started. See below 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
systemctl isolate emergency and systemctl emergency have the same results unfortunately.. 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!!!!!
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.
Am 28.11.21 um 12:37 schrieb westlake: 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). Fwiw, his name is Lennart. 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
I discussed this with upstream in the context of https://github.com/systemd/systemd/pull/23863#issuecomment-1169866253 They rejected the idea of automatically stopping journald when entering rescue mode. The correct way of making journald stop logging to /var (and keeping /var or / busy), is to use `journalctl --relinquish-var` in the case you want to fsck those file systems. Michael