Bug#829180: possible root cause identified

Daniel Pocock daniel at pocock.pro
Mon Jan 16 06:31:37 GMT 2017


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 16/01/17 07:05, Michael Biebl wrote:
> Am 14.01.2017 um 15:49 schrieb Daniel Pocock:
> 
>> I've removed the file 99-btrfs.rules now and put the system in a
>> reboot loop for about 45 minutes, it rebooted about 18 times
>> without the mounts failing any more.
> 
> Glad you figured it out. I'm closing this bug report, see below.
> 
>> Therefore, I feel it is likely this udev file, combined with
>> systemd attempting mounts much earlier, was the reason the mounts
>> were intermittently failing.
>> 
>> While I understand that systemd may not be able to identify
>> every specific irregularity like this, some ideas for improvement
>> come to mind:
>> 
>> - when systemd finds the udev file (99-btrfs.rules was mentioned 
>> in the journalctl output), could it be more conservative by
>> default and delay trying to mount any devices that are associated
>> with udev rules like this?
>> 
> 
> I don't think it's systemd's business to clean up such a btrfs
> rules file. This should be done by the admin who created the file.
> After all, how are we supposed to decide whether the file is buggy
> or actually needed. Even then, a better package to handle such a
> clean up would be btrfs-tools.
> 


The file itself was not buggy.  The combination of that file+SysVinit
was a working environment.  The combination of that file+systemd was
an unstable environment.

It wouldn't be fair to expect systemd to know about every individual
case like this.

However, if systemd does know that a udev rule exists for a particular
device, whether it is this file or any other file that somebody has
created by hand, wouldn't it be reasonable to delay that mount?

I tested running "btrfs device scan" at the command line and the
command appears to complete synchronously.  If the command had started
a background operation then it would be harder for systemd to know the
device was not ready to mount.

Regards,

Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYfGjJAAoJEGxlgOd711bES1gQAIeUD3Ot4l5MuODPc/gHxDwM
ncXGxyBdjaNI7pJnaVO63A2HC5rxYSkEZ1qKZFYr7joNqpJOcZY9irzfMaB9kZ2l
4mSyBL/qEeSftK5F98mOG8lLT+a/KBTLMnAxiejAo3ddhsW5oy164a2DFKYooljs
hgTGbwkymSUGurftC2Ev6v7pzN3LgKuyDblVV1sH8k0ifOw49rRd8LLOt+KUgMq+
/1EE+gd42ASl82i+X3WznRPTKIXw6EUqSChgtSjg4OEBpf6yT4SSRgpPEWNv8xnv
O+G5N263RVLjdU6HXslAMn53eUrBQTFohPPrEiFoFlG8mPjQUb70iC547Trtqfml
cp1PWNzcntd5Viz56kPXiULygt4iNvgxHtx7pDB49Ucw3ZAXwOA2PoiiSRebg/ND
qCL4ZHps8DEnQRl6agKddAOuGAF1edUgemy6s4kLyWo02BJfkX4oDX+rtYrKsX7p
9JliSW+2MRE1TBi0FHHqcvWyp0iJlWNDjSpL/wsQ6gKssJJExBAIlHYHIU+pedkH
t22h30NMkrCR1HjuV0jiC3KPzp86vO8MAWKcFTF9E6yAQgGt2tu/N7wkb+xBFqf1
yYcP8mR7EKhqkiUxBWUXkq4jrgSUOtNzVKiKW7elGbMuUxJyVqnuFOzvZnyM/bzJ
0mMfEWFfaZWJel43Zk20
=1W+t
-----END PGP SIGNATURE-----




More information about the Pkg-systemd-maintainers mailing list