Re: Btrs vs ext4. Which one is more reliable?
On 11-08-17, Christian Seiler wrote:
> 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).
>
Thank you for suggestion. I did find that solution, some time ago, can't
remember exactly where. But it was followed by warning that it is bad
idea, can't remember exactly why. Do you have any hint of why it could
be bad idea to limit timeout, or I've just misunderstood whatever I've
read about it?
> > 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
>
Thank you for your explanation. I do understand why it is happening, did
some reading about that subject even before I've ran on that bug, but it
is still annoying. As for more reliable during shutdown part, not in
my experience, at least on Stretch. It was on Jessie though, where that
feature was hitting me not more than once in every 15-20
shutdowns/reboots.
Anyway, thank you for your time and help.
Reply to: