Bug#999695: systemd: emergency/rescue targets fail to stop journald

Michael Biebl biebl at debian.org
Thu Jun 2 09:35:12 BST 2022


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20220602/4a6161e4/attachment.sig>


More information about the Pkg-systemd-maintainers mailing list