Re: Btrs vs ext4. Which one is more reliable?
Am 2017-08-10 16:02, schrieb Dejan Jocic:
On 10-08-17, David Wright wrote:
On Thu 10 Aug 2017 at 07:04:09 (-0400), Dan Ritter wrote:
> On Wed, Aug 09, 2017 at 09:46:09PM -0400, David Niklas wrote:
> > On Sat, 29 Jul 2017 04:59:40 +0000
> > Andy Smith <andy@strugglers.net> wrote:
> >
> > Also, my use case is at home where the power can and *does* fail. I also
> > find myself using the latest kernel and oftentimes an experimental driver
> > for my AMD graphics card, hence my need for a *very* stable fs over
> > sudden unmount.
>
> Buy a cheap UPS with a USB or serial connection to your
> computer. Even if it only supplies power for 2 minutes, that's
> enough time for the computer to receive the power outage signal
> and do an orderly shutdown.
Two minutes barely covers the timeouts that can often occur when
shutting down systemd; the commonest timeout period here seems
to be 90 seconds. I wouldn't mind reducing them if that's possible.
Processes got just a few seconds with sysvinit before they were
killed.
Yes, those 90 sec waiting for nothing is one of the most annoying
"features" of systemd that I would love to get rid of.
You can set TimeoutStopSec= for some units explicitly, for example
via drop-in. Example:
mkdir -p /etc/systemd/system/XYZ.service.d
cat > /etc/systemd/system/XYZ.service.d/stop-timeout.conf <<EOF
[Service]
TimeoutStopSec=10s
EOF
Even if the service is only provided by an init script this will
still work.
You can also set DefaultTimeoutStopSec= in /etc/systemd/system.conf
to alter the default for all units (though individual settings for
units will still override that).
And most annoying
aspect of it is that problem is rarely constant. It can exist in one
release in systemd, vanish in other, and then come back again in next
release. And it can occur once in every 10 shutdowns/reboots, or not
occur once in every 10 shutdowns/reboots.
That is an indication that you have a race condition during
shutdown.
The "90s" thing is basically just systemd saying: yeah, I've tried
to shutdown a specific unit and it's still active, now I'm going
to wait for the timeout before I send a hard SIGKILL. You can't
really compare that to sysvinit, because sysvinit doesn't actually
track processes properly, so what most often would happen is that
the init script would send a TERM signal to a process, the better
ones maybe also a KILL signal after some time, before they'd just
consider the service stopped. But if other processes had been
started by the service, sysvinit wouldn't care about them, and
only kill those in the final "let's kill all that's still left
over" killing spree. systemd by contrast actually tracks what's
happening with a service and kills the remaining processes.
That said: what could happen here is that the systemd unit created
for a given service has a bug. For example it could not be ordered
correctly and hence systemd tries to stop it too early while other
services still depend on it.
Or the stop command that is called by systemd hangs because it
tries to do something that it shouldn't do during shutdown (for
example start another service).
See the following page for information on how to debug shutdown
issues with systemd (and keep in mind that Debian has systemd stuff
installed in /lib and not /usr/lib):
https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1
I've found systemd to be far more reliable during shutdown (even
if you have to wait for a timeout if something's gone wrong),
because at least there is a timeout. With sysvinit I've sometimes
had the problem that a shutdown script would hang and then nothing
further would happen and the computer would never properly shut
down. This was especially frustrating with headless machines. What
systemd does do is make it much more apparent if there's a
misconfiguration somewhere.
Regards,
Christian
Reply to: