Systemd 232 Coming Soon With Numerous New Features

[pal666]

I can't blame uid313 for his (or her) confusion about what systemd-mount does.

surely you can. he didn't try to look for explanation, he just assumed his idiotic fantasy

[Stellarwind]

From Lennart

Translation: mounting filesystems is harder than we thought and it often didn't work under systemd, because it was stupid enough to shut down network before nfs was unmounted, so we had to come up with even more crap to fix this mess.

[RahulSundaram]

Translation: mounting filesystems is harder than we thought and it often didn't work under systemd, because it was stupid enough to shut down network before nfs was unmounted, so we had to come up with even more crap to fix this mess.

systemd doesn't shutdown nfs by itself without shutting off network if the ordering on the nfs service is correct. What's the bug report on that? That doesn't seem related to a mount wrapper which is useful in precisely the scenarios that has nothing at all to do with nfs.

[srakitnican]

Stellarwind, no idea what you are talking about, you mount disks using mount command + fstab. For network mounts, did you try to add dependency for your mount "x-systemd.requires=network.target" ...?

[jrch2k8]

Translation: mounting filesystems is harder than we thought and it often didn't work under systemd, because it was stupid enough to shut down network before nfs was unmounted, so we had to come up with even more crap to fix this mess.

You make it sound like SysV bash era was any better, nice try to troll

In systemd 231- or any other init system(outside recent enough solaris OS) having to umount an networked filesystem (ceph, nfs, samba, AFS, etc.) can generate race conditions or partial/missed writes(depends if it support atomic operations) due to the fact there is no way for the services to inform the init system "perfectly" when there are current operations(specially messy with forked child processes on write operations). This + systemd dbus API can be a trully effective solution that would allow both services to talk and agree when is safe to continue the shutdown/restart process

The same is true at boot, is very weird to find a distro with enough dark magic bash on the init files to be able to mount networked filesystems when something weird happens(for example FSCK taking long time on main drive while NFS fail to find mount point path, just a simple example of the million things that can go wrong when mounting networked FS). This should help a lot here too.

[starshipeleven]

Translation: I'm an idiot and can't configure my services correctly, so I blame whatever else

Really, systemd follows configs (also scripts do if someone isn't an idiot), if someone is an idiot and didn't specify that such service should wait for X and Y other services how in the hell can it know that on its own?

It's an init system damnit, not an AGI nanny for noobs.

[acobar]

From Lennart

Second: through systemd's job scheduler we can schedule an fsck invocation before the first access. This means: we can automatically fix up the fs should it end up being uncleanly unplugged after all.

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.

[tinko]

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.

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.

[Stellarwind]

Stellarwind, no idea what you are talking about, you mount disks using mount command + fstab. For network mounts, did you try to add dependency for your mount "x-systemd.requires=network.target" ...?

I'm talking about something like this issue: https://bugs.debian.org/cgi-bin/bugr...cgi?bug=798314
Yes, you need dependency, but network.target is not enough. Systemd way seems good in simple cases, but you end up in a dependency hell very quickly.
With sysvinit this was usually not a problem, because startup/shutdown was done in a specific order. Slower, but much more reliable and debuggable,

I'm not saying that sysvinit way is always better btw, just that relying 100% on dependency tree is a mess.

[Stellarwind]

Also network.target is a root of lots of confusion, because simply requiring it does not mean that network is configured by the time it is fired.
Eventually you figure out how to deal with it, but you are in love with sysv/upstart and even solaris SMF with its xml configs at that point.