Joey Hess Resigns From Debian, Unhappy With How It's Changed

[gerddie]

The credo, "if a program have to fail, have it fail early and fail noisily", is actually "Unix Philosophy", see here under the "Rule of Repair". http://en.wikipedia.org/wiki/Unix_philosophy

So systemd is following traditional Unix development here when a mount point in fstab fail to boot, instead of allowing a potentially "silent" data corrupting behaviour like SysVinit distro does.

I risk to differ: nofail just implies that no error message is given when a mount fails. Its absence doesn't implicate any specific behaviour from the process calling "mount", this is up to the caller. In sysvinit (and afaik also in openrc) the failure is mostly ignored, unless it is the root partition that can not be mounted. Systemd changes this long established behaviour, and requires that nofail needs to be specified for disks that may not be critical for the system to boot, ignoring that it may still be a good idea to get an actual error message if the mount fails. Here I'm thinking of servers where one has no direct access to the console, with one of these you wouldn't want to drop into a local console unless absolutely necessary (e.g. if root fails to mount).

Assuming that every disk is critical unless told otherwise seems to be the best overall strategy.

But nofail goes beyond that, nofail suppresses any error message related to a failed mount, which may not be the intended approach, but seems to be the recommended approach for systemd based installations.

[SebastianB]

that's why there is /etc/mtab and /proc/mounts

grep "/my/mount" /proc/mounts || { echo 'thing not mounted, can't sync it' ; exit 1; }

and if it won't be mounted, you will still be able to fully boot your computer

note that an init will run fsck on / before booting, and that should be the only error that deserves a critical status
idk, does systemd even run fsck by default ?

Thats a bandaid for this specific case and you know it. We are talking about sane defaults here and stopping the boot when failing to bring up a mount thats not marked as nofail is plainly sane. A failed mount either means something harmless or something very disrupting and significiant, and its the job of the systemadmin to tell the system which of the two it is.

Assuming everything is fine aslong as the system comes up somehow is imho wrong, the purpose of a system isn't running itself, but the sometimes critical software like databases and sometimes even GUI applications and a mount failure may very well impact them even if the system bootup itself is fine. If a mount is noncritical to your systems purpose, add the nofail switch to it. Mounting the drive of a second OS on your system plainly shouldn't fail your boot, but how the hell is your init to know that it can safely ignore a certain mount and not another? By the admin setting the nofail flag. Not by guessing, not by some invariably flawed autodetection and not by just trying to boot and see what happens. If things like /tmp or an external /var/log fail on a diskless machine(or one with very limited resources, say a container) it may well bring the whole system down for good by filling up the /.

Maybe im missing something, but in what situation would you want to bring up a system with failed static mounts that don't warrant the nofail switch? Its not like your dropped into a kernel panic, you have a console and can investigate the problem ... that seems sane.

[SebastianB]

I risk to differ: nofail just implies that no error message is given when a mount fails. Its absence doesn't implicate any specific behaviour from the process calling "mount", this is up to the caller. In sysvinit (and afaik also in openrc) the failure is mostly ignored, unless it is the root partition that can not be mounted. Systemd changes this long established behaviour, and requires that nofail needs to be specified for disks that may not be critical for the system to boot, ignoring that it may still be a good idea to get an actual error message if the mount fails. Here I'm thinking of servers where one has no direct access to the console, with one of these you wouldn't want to drop into a local console unless absolutely necessary (e.g. if root fails to mount).

But nofail goes beyond that, nofail suppresses any error message related to a failed mount, which may not be the intended approach, but seems to be the recommended approach for systemd based installations.

The nofail option literally means "i don't care if this doesn't work, don't bother me" to your system. Also the fstab is traditionally for static configuration, devices that sometimes are available and sometimes not shouldn't be put there. Create a seperate unit file for those. On my system for example i have only 5 entries in it, /boot, /, /home, swap and my NAS. Since my NAS provides subfolders to my ~home each of those failing would be critical regardless of wether the rest of the system comes up. The other ~28 mounts on my system ... well to hell if i actually know where they are coming from these days. And hell if i know why a system these days needs 32 something mounts for normal operation but thats not our topic apparently ...

Edit: mount -a failing on a nofail line in fstab still gives out an error on console, but it won't be logged regardless of wether you have set nofail or not.

[interested]

I risk to differ: nofail just implies that no error message is given when a mount fails. Its absence doesn't implicate any specific behaviour from the process calling "mount", this is up to the caller. In sysvinit (and afaik also in openrc) the failure is mostly ignored, unless it is the root partition that can not be mounted. Systemd changes this long established behaviour, and requires that nofail needs to be specified for disks that may not be critical for the system to boot, ignoring that it may still be a good idea to get an actual error message if the mount fails. Here I'm thinking of servers where one has no direct access to the console, with one of these you wouldn't want to drop into a local console unless absolutely necessary (e.g. if root fails to mount).

Sure, one could argue that since this wrong, buggy and dangerous behaviour have been the norm for so long it is now a "feature" that should be used forever no matter what initsystem the future brings.

Others, that includes the systemd developers, think that doing so will cover up fundamental problems; if there is a problem with mount points in fstab, it is either a dead disk, or an man made error when editing the fstab file. In both cases this could lead to serious errors, and should be dealt with ASAP. Again, the systemd behaviour is the "correct" behaviour according to Unix/Linux design principles and it can prevent serious "silent" data loss.

Such a fundamental change as a brand new init system is a perfect opportunity to deprecate "bad" system behaviour of the old init system.

But nofail goes beyond that, nofail suppresses any error message related to a failed mount, which may not be the intended approach, but seems to be the recommended approach for systemd based installations.

"nofail" is only recommended for statically mounted disks you _really_ don't care about whether they show up or not when booting, including seeing it in the logs. (at least on default log level).

Using the "nofail" option permanently on important system mount points to cover up for admin mistakes when editing fstab is really bad practice and is not recommended. Yeah I saw someone on a Debian mailing list that suggested to mark all fstab entries "nofail" to avoid whining from cowboy admins that upgrade to a new OS without reading the release notes. IMHO, that will only delay the problems.

[BeardedGNUFreak]

Watching the systemd fiasco continue to unfold through the Linux 'community' is an absolute joy to watch week by week from my perfect Unix workstation running FreeBSD 10.

The best part of the systemd fiasco is it is only going to get better over the coming years.

* Screams of anger at 'who let this disaster happend???'
* Angry finger pointing at those responsible for allowing systemd to infest their Linux distributions
* Cries of pain at how long it will take to rip out the garbage systemd code and replace it
* Cries of pain at how long it will take to undo the wasted work in projects that were dumb enough to hardcode systemd dependencies into their codebase

You would think even the 15 year old Slashdot kiddies who make up the bulk of Linux users would have noticed the systemd fiasco has turned Linux into the laughingstock of the computing world.

systemd - it's funny because it's not happening to me.

[gens]

Thats a bandaid for this specific case and you know it. We are talking about sane defaults here and stopping the boot when failing to bring up a mount thats not marked as nofail is plainly sane. A failed mount either means something harmless or something very disrupting and significiant, and its the job of the systemadmin to tell the system which of the two it is.

Assuming everything is fine aslong as the system comes up somehow is imho wrong, the purpose of a system isn't running itself, but the sometimes critical software like databases and sometimes even GUI applications and a mount failure may very well impact them even if the system bootup itself is fine. If a mount is noncritical to your systems purpose, add the nofail switch to it. Mounting the drive of a second OS on your system plainly shouldn't fail your boot, but how the hell is your init to know that it can safely ignore a certain mount and not another? By the admin setting the nofail flag. Not by guessing, not by some invariably flawed autodetection and not by just trying to boot and see what happens. If things like /tmp or an external /var/log fail on a diskless machine(or one with very limited resources, say a container) it may well bring the whole system down for good by filling up the /.

Maybe im missing something, but in what situation would you want to bring up a system with failed static mounts that don't warrant the nofail switch? Its not like your dropped into a kernel panic, you have a console and can investigate the problem ... that seems sane.

where did you see a guess in what i said ?

and the context was not about a mount like /tmp or anything used by the whole system, it was about some specific program requiring a specific, custom, mounted directory
if you mount /tmp or /var/log separately you need to check if it is mounted at boot and deal with it if it isn't, as anyone with half a brain can tell you
to be cynical; if you mount /usr separately you need to use something that is not systemd


if a program needs a specific mount that is not part of a system, the program has to check at start if it is mounted as that is the only way it can be sure
real example:
i have a disk that i use for movies
it is a very old disk that 1 in 30 boots fails to mount (and before you start, it would fail with systemd too)
i have rtorrent that automatically starts to download in a specific directory
the only sane solution is to try to mount it again (that is questionable if an init should do by default, as trying to access a broken disk can break it even more)
but it should not make my computer boot for 15min


short story
system vital mounts = important and boot breaking
non vital mounts = give warning and continue boot

anything else not clear ?

[psychoticmeow]

Watching the systemd fiasco continue to unfold through the Linux 'community' is an absolute joy to watch week by week from my perfect Unix workstation running FreeBSD 10.

The best part of the systemd fiasco is it is only going to get better over the coming years.

* Screams of anger at 'who let this disaster happend???'
* Angry finger pointing at those responsible for allowing systemd to infest their Linux distributions
* Cries of pain at how long it will take to rip out the garbage systemd code and replace it
* Cries of pain at how long it will take to undo the wasted work in projects that were dumb enough to hardcode systemd dependencies into their codebase

You would think even the 15 year old Slashdot kiddies who make up the bulk of Linux users would have noticed the systemd fiasco has turned Linux into the laughingstock of the computing world.

systemd - it's funny because it's not happening to me.

So you masturbate to the complaints of misinformed idiots? We needed to know that... no really...

[MoonMoon]

where did you see a guess in what i said ?

and the context was not about a mount like /tmp or anything used by the whole system, it was about some specific program requiring a specific, custom, mounted directory
if you mount /tmp or /var/log separately you need to check if it is mounted at boot and deal with it if it isn't, as anyone with half a brain can tell you
to be cynical; if you mount /usr separately you need to use something that is not systemd


if a program needs a specific mount that is not part of a system, the program has to check at start if it is mounted as that is the only way it can be sure
real example:
i have a disk that i use for movies
it is a very old disk that 1 in 30 boots fails to mount (and before you start, it would fail with systemd too)
i have rtorrent that automatically starts to download in a specific directory
the only sane solution is to try to mount it again (that is questionable if an init should do by default, as trying to access a broken disk can break it even more)
but it should not make my computer boot for 15min


short story
system vital mounts = important and boot breaking
non vital mounts = give warning and continue boot

anything else not clear ?

Just write a .mount file for that specific mount, let it retry for a reasonable amount of tries and make rtorrent dependent on that. This way you let the init system do what it is made for and don't have to rely on hacks using Bash scripts. Your sane solution is possible and easy to set up using systemd's capabilities, no need a Bash workaround.

[gens]

Just write a .mount file for that specific mount, let it retry for a reasonable amount of tries and make rtorrent dependent on that. This way you let the init system do what it is made for and don't have to rely on hacks using Bash scripts. Your sane solution is possible and easy to set up using systemd's capabilities, no need a Bash workaround.

i start rtorrent manually, not the init (it can't even be controlled without a terminal)
and that is not the solution even if the init did start it

hacks ?
systemd wouldn't start the program if i told it to do that, and it would probably hang until timeout as some people write

[grndzro]

Watching the systemd fiasco continue to unfold through the Linux 'community' is an absolute joy to watch week by week from my perfect Unix workstation running FreeBSD 10.

The best part of the systemd fiasco is it is only going to get better over the coming years.

* Screams of anger at 'who let this disaster happend???'
* Angry finger pointing at those responsible for allowing systemd to infest their Linux distributions
* Cries of pain at how long it will take to rip out the garbage systemd code and replace it
* Cries of pain at how long it will take to undo the wasted work in projects that were dumb enough to hardcode systemd dependencies into their codebase

You would think even the 15 year old Slashdot kiddies who make up the bulk of Linux users would have noticed the systemd fiasco has turned Linux into the laughingstock of the computing world.

systemd - it's funny because it's not happening to me.

You sound incredibly buthurt about SystemD......
MABYE YOU SHOULD HAVE ACTUALLY READ THE DOCUMENTATION BEFORE FRACKING WITH IT?