Bug#754340: Unable to run fsck manually when instructed to do so

[Michael Biebl]

Am 14.07.2014 16:00, schrieb Michael Biebl:
> emergency.target only has Requires/After=emergency.service, so I'd
> expect fewer services to be running then in rescue.target since isolate
> should stop all other services.

Apparently the documentation doesn't match the code:


> <mbiebl_> hm, so the systemd-fsck man page says, if fsck fails, it will isolate to emergency.target
> <mbiebl_> looking at src/fsck/fsck.c though
> <mbiebl_> it seems to replace basic.target instead
> <mbiebl_> i.e., if I'm dropped into emergency target (due to a failing fsck) I still having processes running keeping the fs busy
> <mbiebl_> so I can't remount / ro
> <mbiebl_> those processes are from services being started in sysinit.target
> <mbiebl_> is the man page incorrect or the code?
> <mbiebl_> afaics, "isolate emergency.target" should stop all processes besides the ones listed as dependencies of emergency.target
> <mbiebl_> (which would only be emergency.service)
> <dreisner> mbiebl_: that isn't how i read the code
> <dreisner> it seems to either start reboot.target or emergency.target. but this will only be done if the transaction to replace basic.target with one of these isn't destructive (???)
> <mbiebl_> dreisner: well, my point is, that systemctl isolate emergency.target
> <mbiebl_> would stop all process besides the dependencies of emergency.target
> <mbiebl_> and the man page of systemd-fsck says, that isolate emergency.target happens
> <mbiebl_> when I get a failing fsck, I still have all processes of sysinit.target running
> <mbiebl_> so either the code or the man page is incorrect, imo
> <mbiebl_> dreisner: don't you agree there's a mismatch between what's documentend and what actually happens?
> <dreisner> well there's no mention of isolating reboot.target
> <mbiebl_> dreisner: man systemd-fsck: "If a file system check fails,
> <mbiebl_>        emergency mode is activated, by isolating to emergency.target."
> <dreisner> which is what the code says?
> <mbiebl_> is it?
> <dreisner> 386                 else if (status.si_code == CLD_EXITED && (status.si_status & 6))
> <dreisner> 387                         /* Some other problem */
> <dreisner> 388                         start_target(SPECIAL_EMERGENCY_TARGET);
> <dreisner> '6' seems wrong...
> <mbiebl_> it starts the target, but doesn't seem to isolate to it
> <dreisner> is isolating what you want to do, though?
> <mbiebl_> sure
> <mbiebl_> when you want to remount / ro
> <mbiebl_> you better don't have any services running keeping the fs busy
> <dreisner> i'm thinking of a case where the system is already booted and an automount triggers a fsck (which subsequently fails)
> <dreisner> if you isolate emergency.target, you're going to have a bad time.
> <dreisner> which is probably why the logic is written as it is, replacing, rather than isolating. so, sure, i guess the documentation is wrong?
> <mbiebl_> shouldn't we rather treat then such "early" mounts differently then automounts
> <mbiebl_> not being be able to remount / ro and fsck your system isn't great either
> <dreisner> i don't understand why you need to remount. how/why is fsck running on a system that isn't already RO?
> <mbiebl_> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754340


That means, potentially, all services from sysinit.target (that includes
/etc/rcS.d/) are running. So there is certainly a chance that one of
those services keeps / busy.


I've CCed Lennart here. Maybe he can shed some light on why rescue mode
doesn't use isolate but replace.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140714/a2cc6d63/attachment-0002.sig>