This is a regression from version 216 -> 217 related to the old bug: https://bugzilla.redhat.com/show_bug.cgi?id=1017509 I'm running test cases for nixos which specifies swap devices in the fstab and I'm noticing transient failures of the swap target like this: http://hydra.nixos.org/build/17657871/log/raw http://hydra.nixos.org/build/17656870/log/raw http://hydra.nixos.org/build/17657013/log/raw We started noticing these transient failures after pushing systemd from 212 -> 217. This was also observed by an archlinux user: https://archlinux.org.ru/forum/topic/14196/
(In reply to William A. Kennington III from comment #0) > This is a regression from version 216 -> 217 related to the old bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1017509 > > I'm running test cases for nixos which specifies swap devices in the fstab > and I'm noticing transient failures of the swap target like this: > http://hydra.nixos.org/build/17657871/log/raw > http://hydra.nixos.org/build/17656870/log/raw > http://hydra.nixos.org/build/17657013/log/raw > > We started noticing these transient failures after pushing systemd from 212 > -> 217. > > This was also observed by an archlinux user: > https://archlinux.org.ru/forum/topic/14196/ Actually, the correct old bug report is this: https://bugs.freedesktop.org/show_bug.cgi?id=69835
I can confirm this on Debian testing with systemd 215-7 Seems like systemd-fstab-generator and systemd-gpt-auto-generator are competing with each other. In the freedesktop documentation, it says that systemd should run the fstab generated unit file first before using the gpt auto generated unit file. However, it seems like they're running at the same time, resulting in a race condition. Sometimes swap is mounted via the fstab entry and other times it's mounted via the gpt-auto-generator. This isn't a problem for people who don't mess around with the fstab entry and leave it as default. But for people who have SSD drives and enable the discard option for their swap partition via fstab, this becomes problematic since it isn't guaranteed that fstab will run first and apply the discard. Indeed sometimes my swap gets automounted and the fstab mount will fail with "Device or resource busy".
Well no, this is still problematic because it causes the swap.target to fail when in reality it should be succeeded. There is no reason it should generate two swap mounts for the same swap device.
(In reply to William A. Kennington III from comment #3) > Well no, this is still problematic because it causes the swap.target to fail > when in reality it should be succeeded. There is no reason it should > generate two swap mounts for the same swap device. Of course, this should definitely be fixed because that's incorrect behavior.
This should be fixed by http://cgit.freedesktop.org/systemd/systemd/commit/?id=37cf8fe. Can you check?
Pretty sure this works correctly now. Closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.