Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #185049

Re: Btrs vs ext4. Which one is more reliable?

Show all headers | View raw

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

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Btrs vs ext4. Which one is more reliable? David Niklas <doark@mail.com> - 2017-08-10 06:10 +0200
  Re: Btrs vs ext4. Which one is more reliable? Dan Ritter <dsr@randomstring.org> - 2017-08-10 13:10 +0200
    Re: Btrs vs ext4. Which one is more reliable? David Wright <deblis@lionunicorn.co.uk> - 2017-08-10 15:50 +0200
      Re: Btrs vs ext4. Which one is more reliable? Dan Ritter <dsr@randomstring.org> - 2017-08-10 16:10 +0200
      Re: Btrs vs ext4. Which one is more reliable? Dejan Jocic <jodejka@gmail.com> - 2017-08-10 16:10 +0200
        Re: Btrs vs ext4. Which one is more reliable? Christian Seiler <christian@iwakd.de> - 2017-08-11 18:00 +0200
          Re: Btrs vs ext4. Which one is more reliable? Dejan Jocic <jodejka@gmail.com> - 2017-08-11 18:30 +0200
            Re: Btrs vs ext4. Which one is more reliable? Christian Seiler <christian@iwakd.de> - 2017-08-11 19:20 +0200
              Re: Btrs vs ext4. Which one is more reliable? David Wright <deblis@lionunicorn.co.uk> - 2017-09-01 03:50 +0200
                Re: Btrs vs ext4. Which one is more reliable? Henrique de Moraes Holschuh <hmh@debian.org> - 2017-09-01 13:40 +0200
                Re: Btrs vs ext4. Which one is more reliable? David Wright <deblis@lionunicorn.co.uk> - 2017-09-01 18:00 +0200
      Re: Btrs vs ext4. Which one is more reliable? Gary Dale <garydale@torfree.net> - 2017-08-11 17:00 +0200
    Re: Btrs vs ext4. Which one is more reliable? Andy Smith <andy@strugglers.net> - 2017-08-12 05:10 +0200
      Re: Btrs vs ext4. Which one is more reliable? Zenaan Harkness <zenaan@freedbms.net> - 2017-08-12 09:00 +0200
      Re: Btrs vs ext4. Which one is more reliable? rhkramer@gmail.com - 2017-08-12 15:20 +0200

csiph-web