Systemd 232 Coming Soon With Numerous New Features

[interested]

This is really a bad idea. All fixes must be explicitly called or you may risk ruining the work of someone else, even though you had the best of the intentions. Hard learned lesson.

I don't think the world agrees with you on that. Are there any distro's that aren't defaulting to using the "preen" option with fsck when booting, so that errors that can be *safely* fixed, are fixed automatically?

Anyway, the point is that systemd-mount allows you to *check* the state of the FS before mount and later access, which is always a good idea. It can also ensure that the eg. USB stick FS will be unmounted when idle (one second after it was last accessed) and then automounted when accessed again. That will ensure, that even if people forget to unmount their USB stick before removing it, its FS is likely to remain clean. Both ideas are super improvements.

If fsck finds an error that can be easily and safely fixed by it (preen), it really should do so automatically as default, at least for native Linux FS'. What is a realistic alternative to that?

[Ericg]

Can you give further explanation on this? Because I think I remember seeing messages about fixes to the fs on the first boot after losing power or sth. like that without explicitly stating that I wanted it to be fixes. How would an fs fix ruin someones work? I imagine that fix would mean that some low-level tree- or hashmap-structure is fixed from inconsistencies introduced through unfinished operations. If that destroys some data that could have been recovered, wouldn't that suggest that the fixing process should be changed? Are there ambiguities in fixing filesystems? Wouldn't it be just as dangerous to leave the fs in an inconsistent state?

Can you give an example of what you mean? Your last sentence suggests, that you have encountered some.

Correct, an fsck will automatically be invoked every nth number of mounts for many distros, or by creating the file /forcefsck. Probably 99% of the time, this is totally fine. Where you run into issues is if you pervasive filesystem damage and try to fsck it. It is totally possible for an fsck to, in trying its best to fix it, make the problem even worse and hose the filesystem. The worse the existing damage, the more likely an fsck is to mess it up. And unfortunately removable media is more likely to be damaged, both on a physical level, and on a "you didnt cleanly unmount me after the last use, im in an inconsistent state" level.

[starshipeleven]

I'm talking about something like this issue: https://bugs.debian.org/cgi-bin/bugr...cgi?bug=798314

So, a severe case of not RTFM?
Really, it's stated here, in the page about network units. https://www.freedesktop.org/wiki/Sof...NetworkTarget/
"network.target has very little meaning during start-up. It only indicates that the network management stack is up after it has been reached. Whether any network interfaces are already configured when it is reached is undefined. It's primary purpose is for ordering things properly at shutdown: since the shutdown ordering of units in systemd is the reverse of the startup ordering, any unit that is order After=network.target can be sure that it is stopped before the network is shut down if the system is powered off. This allows services to cleanly terminate connections before going down, instead of abruptly losing connectivity for ongoing connections, leaving them in an undefined state. Note that network.target is a passive unit: you cannot start it directly and it is not pulled in by any services that want to make use of the network. Instead, it is pulled in by the network management service itself. Services using the network should hence simply place an After=network.target dependency in their unit files, and avoid any Wants=network.target or even Requires=network.target."

And what does fix the issue in that bug report? adding a dependency on network.target in fstab. Ummmmmm....

With sysvinit this was usually not a problem, because startup/shutdown was done in a specific order. Slower, but much more reliable and debuggable,

More like startup/shutdown happened regardless of services, so if nfs decided to lock up like in this case sysvinit would have simply not given a fuck and closed everything anyway, hiding the problem in its usual way.

[starshipeleven]

removable media is more likely to be damaged, both on a physical level, and on a "you didnt cleanly unmount me after the last use, im in an inconsistent state" level.

Mostly because crappy filesystem (FAT or exFAT). Anything with metadata journaling should have a vastly reduced risk of this. Sure you might have corrupted files but you don't risk fubarring the whole partition.

[nomadewolf]

Systemd needs to have less features, not more...

[starshipeleven]

Systemd needs to have less features, not more...

Yes, it needs to drop all features apart from init scripts, then also the name is too long and lacks a uppercase letter at the end.
We should change it into SysD.

[Tomin]

Yes, it needs to drop all features apart from init scripts, then also the name is too long and lacks a uppercase letter at the end.
We should change it into SysD.

Nah, I don't like upper case letters at the end of word so I think the D should be dropped and it should be just System. And then think what features a software named like that should have.

Seriously though, I write it systemd which is how the devs want it to be written. And I actually like systemd, please don't hate me for that.

Btw, do systemd haters hate busybox as well?

[nomadewolf]

Yes, it needs to drop all features apart from init scripts, then also the name is too long and lacks a uppercase letter at the end.
We should change it into SysD.

You nailed it!

[nomadewolf]

Nah, I don't like upper case letters at the end of word so I think the D should be dropped and it should be just System. And then think what features a software named like that should have.

Seriously though, I write it systemd which is how the devs want it to be written. And I actually like systemd, please don't hate me for that.

Btw, do systemd haters hate busybox as well?

i don't think i am a systemd hater.
i just think it could and therefore should be better.
i does so many things that aren't part of what an init system should do, and that is wrong.
i don't really care if use busybox or sysvinit or systemd.
in fact i use systemd and it works.
i just want it to be better. anything wrong with that?

[nomadewolf]

managed to write 6 sentences started with letter 'i'...