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?
signature.asc
Description: OpenPGP digital signature
