-----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-----