On 2016-10-03 14:54, Andrei Borzenkov wrote:
On Mon, Oct 3, 2016 at 3:41 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
Can you come up with an example of that, Carlos? I think you're wrong. systemd has better options than editing the script - a service unit is easily overridden etc.
Yes, sure.
I had problems with umounting some filesystem and systemd instantly remounting it on my back. Or the other way round.
This is expected to be mitigated (I hesitate to say "fixed") in current upstream systemd. But it also demonstrates one of bad design habits in systemd - doing something implicitly, without making "something" configurable or even documented.
Yep. It is also a problem with not handling traditional fstab usage. It appears that one has to issue a systemctl command to umount things.
One that is hard to reproduce: during halt, network was disconnected, then the process decided to umount an nfs mount. Obviously, it could not, and got stuck. On the end, I had to hit the power button.
Expressed this way it is hardly systemd related at all. All UNIX systems I have been working with would come to a hard stop in this case (depending on exact NFS mount options) including Solaris which is created by the same company that invented NFS in the first place ...
I have only experienced it with systemd. Notice that I'm not talking about a "system" share, like would be "/usr", but a plain data partition that can be umounted early, as soon as user tasks have died. The obvious solution is don't kill network before network shares and other network services exit... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)