Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
Lennart Poettering [2015-01-28 1:03 +0100]: I implemented a different logic now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=37cf8fee46025d704660a9fc1d1349fe7d0b139d With this change we'll now dispatch only one mkswap per device node, regardless which symlinked alias is used to refer to it. I have only given this very light testing, and I am not sure this solves the original problem you reported, hence I'd be thankful if you could check if this makes the problem go away. I built a package with this for Debian and Ubuntu. The Debian reporter in https://bugs.debian.org/772182 confirmed that this is working, I think/hope the Ubuntu reporter in https://bugs.launchpad.net/bugs/1399595 is also usually very responsive, I think he'll report back soon too. So it fixes that problem, thanks! However, in my VM with no GPT, but a simple fstab entry for the swap booting now hangs forever, swap.target doesn't become active any more. I don't have time right now to investigate this further, but I suppose this should be fairly easy to reproduce. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Wed, 28.01.15 14:16, Martin Pitt (martin.p...@ubuntu.com) wrote: Hey Lennart, Lennart Poettering [2015-01-28 14:06 +0100]: Ah, thanks! That was helpful. I apparently fucked up the new linked list iteration macro I added for this. I think this should make it work: http://cgit.freedesktop.org/systemd/systemd/commit/?id=cdda4aa8d20c2679cc937d40e793abe7806f17cb Can you check? Boots fine again, thanks! I suppose this could do with an unit test? :-) Well, there is one actually, except it didn't check for the one corner case that mattered here. I have already queued up a patch that duplicates the test cases for these corner cases. It's actually what I did my testing with to track this down... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
Hey Lennart, Lennart Poettering [2015-01-28 14:06 +0100]: Ah, thanks! That was helpful. I apparently fucked up the new linked list iteration macro I added for this. I think this should make it work: http://cgit.freedesktop.org/systemd/systemd/commit/?id=cdda4aa8d20c2679cc937d40e793abe7806f17cb Can you check? Boots fine again, thanks! I suppose this could do with an unit test? :-) Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
Lennart Poettering [2015-01-28 13:15 +0100]: I built a package with this for Debian and Ubuntu. The Debian reporter in https://bugs.debian.org/772182 confirmed that this is working, I think/hope the Ubuntu reporter in https://bugs.launchpad.net/bugs/1399595 is also usually very responsive, I think he'll report back soon too. So it fixes that problem, thanks! Is the swap device mounted afterwards? Yes, and we also confirmed that it's from the fstab generator, not the gpt one. However, in my VM with no GPT, but a simple fstab entry for the swap booting now hangs forever, swap.target doesn't become active any more. I don't have time right now to investigate this further, but I suppose this should be fairly easy to reproduce. Hmm. Any chance you can boot this in debug mode and get me the last 100 log lines or so when this hangs? Also, could you enable the debug shell and get me the output of systemctl list-jobs? Both at http://people.canonical.com/~pitti/tmp/systemd-debug/ Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Wed, 28.01.15 12:37, Martin Pitt (martin.p...@ubuntu.com) wrote: Lennart Poettering [2015-01-28 1:03 +0100]: I implemented a different logic now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=37cf8fee46025d704660a9fc1d1349fe7d0b139d With this change we'll now dispatch only one mkswap per device node, regardless which symlinked alias is used to refer to it. I have only given this very light testing, and I am not sure this solves the original problem you reported, hence I'd be thankful if you could check if this makes the problem go away. I built a package with this for Debian and Ubuntu. The Debian reporter in https://bugs.debian.org/772182 confirmed that this is working, I think/hope the Ubuntu reporter in https://bugs.launchpad.net/bugs/1399595 is also usually very responsive, I think he'll report back soon too. So it fixes that problem, thanks! Is the swap device mounted afterwards? However, in my VM with no GPT, but a simple fstab entry for the swap booting now hangs forever, swap.target doesn't become active any more. I don't have time right now to investigate this further, but I suppose this should be fairly easy to reproduce. Hmm. Any chance you can boot this in debug mode and get me the last 100 log lines or so when this hangs? Also, could you enable the debug shell and get me the output of systemctl list-jobs? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Wed, 28.01.15 13:41, Martin Pitt (martin.p...@ubuntu.com) wrote: Lennart Poettering [2015-01-28 13:15 +0100]: I built a package with this for Debian and Ubuntu. The Debian reporter in https://bugs.debian.org/772182 confirmed that this is working, I think/hope the Ubuntu reporter in https://bugs.launchpad.net/bugs/1399595 is also usually very responsive, I think he'll report back soon too. So it fixes that problem, thanks! Is the swap device mounted afterwards? Yes, and we also confirmed that it's from the fstab generator, not the gpt one. However, in my VM with no GPT, but a simple fstab entry for the swap booting now hangs forever, swap.target doesn't become active any more. I don't have time right now to investigate this further, but I suppose this should be fairly easy to reproduce. Hmm. Any chance you can boot this in debug mode and get me the last 100 log lines or so when this hangs? Also, could you enable the debug shell and get me the output of systemctl list-jobs? Both at http://people.canonical.com/~pitti/tmp/systemd-debug/ Ah, thanks! That was helpful. I apparently fucked up the new linked list iteration macro I added for this. I think this should make it work: http://cgit.freedesktop.org/systemd/systemd/commit/?id=cdda4aa8d20c2679cc937d40e793abe7806f17cb Can you check? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Tue, 27.01.15 23:31, Lennart Poettering (lenn...@poettering.net) wrote: On Fri, 23.01.15 10:18, Martin Pitt (martin.p...@ubuntu.com) wrote: So perhaps the more robust fix would be to make the gpt generator not generate swap units if fstab already configures any swap device? I. e. auto-discovery and swaps in fstab are mutually exclusive then. Hmm, so there's something fishy here. systemd should already handle this nicely, and I thought I tested this successfully. The logic here is that when we enumerate through /proc/swaps we already check udev to not only then set the device listed in there to active, but also all .swap units that are defined by any of its symlink names. This means, activating a swap partition should result in a number of .swap devices to go active, not just one. THis is visible if you type systemctl -a -t swap, which should show a number of .device units for the same actual swap device... Now, if two jobs are queued to up a swap device, using different names for it, like an entry in fstab, and a GPT auto-discovered partition might do it, then this should mean that one of the jobs should be removed by the effect of the other, i.e. the later job should be immediately succeed, since the other job already caused the swap device to go active. There must be a bug somewhere with this... Any chance you can boot in debug mode and check how the .swap units change states during the boot, and when the jobs for it are enqueued? Hmm, thinking a bit more about this. The problem is probably this one: when the jobs are queued we cannot know that the devices they are queued by are actually the same, hence both are queued. Now, if the .device unit backing the two .swap units, both .swap units are suddenly runnable, and hence systemd forks off swapon for both of them immediately. it will then eventually see that both .swap devices are now active from /proc/swaps, but at that time it already had forked off both mkswap's, and one of them will then fail... I wonder what we can do about this. One approach could be to say that automatically discovered mounts and swaps are always dispatched before the ones from /etc/fstab. By serializing things it would be guaranteed that one of the mkswaps runs first, thus brining up both .swap units, so that the second mkswap would not be done, since the .swap would already be up... That said, it would of course be nicer if we wouldn't have to serialize here... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On 01/28/2015 12:24 AM, Lennart Poettering wrote: On Tue, 27.01.15 17:17, Chris Murphy (li...@colorremedies.com) wrote: The problem is simply that we cannot know in advance that /dev/sda7 and /dev/disk/by-uuid/c0e7978b-f82b-4b7f-b72b-6717f6909abc will eventually refer to the same device. Are these just scary looking warnings? It should be unproblematic, but it looks scary right now. The swapon will only succeed once, and fail the second time, and that doesn't look pretty, but the kernel should do the right thing and not get confused by this. I can confirm it does and I simply remove the swap entry in fstab to make it go away when I encountered it. That said are there any real practical benefits of using swap et al in today's age or are people just still creating it out of habit? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Tue, Jan 27, 2015 at 5:28 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 01/28/2015 12:24 AM, Lennart Poettering wrote: On Tue, 27.01.15 17:17, Chris Murphy (li...@colorremedies.com) wrote: The problem is simply that we cannot know in advance that /dev/sda7 and /dev/disk/by-uuid/c0e7978b-f82b-4b7f-b72b-6717f6909abc will eventually refer to the same device. Are these just scary looking warnings? It should be unproblematic, but it looks scary right now. The swapon will only succeed once, and fail the second time, and that doesn't look pretty, but the kernel should do the right thing and not get confused by this. I can confirm it does and I simply remove the swap entry in fstab to make it go away when I encountered it. That said are there any real practical benefits of using swap et al in today's age or are people just still creating it out of habit? For those who have hibernation working, it's needed. And there's a case for it on baremetal servers, it's sometimes better that they slow down instead of totally face planting. And it can be useful if you don't have enough memory to do a full fsck on a large file system, especially if swap is on an SSD it's not as slow as on a HDD. But otherwise, maybe not. Over on that other OS that begins with W, it looks like they aren't using swap directly. Instead there's a separate Intel Rapid Start specific partition (it has it's own GPT partition type GUID) that puts some kind of hibernation like file there on normal shutdown. Cold boot times are insanely fast, like 3-4 seconds from pushing the button. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On 01/27/2015 10:48 PM, Lennart Poettering wrote: Another idea might be to simply accept that activating the swap by two names at the same time can happen concurrently, and teach mkswap in some way to handle this gracefully. For example, mkswap could learn a new switch --idempotent or so, which we could always pass from systemd. If set and if activating the swap fails with EBUSY because the swap is already activated it would eat that up and return success. Is not the problem here that we are using two generators to parse this? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Tue, 27.01.15 23:48, Lennart Poettering (lenn...@poettering.net) wrote: That said, it would of course be nicer if we wouldn't have to serialize here... Another idea might be to simply accept that activating the swap by two names at the same time can happen concurrently, and teach mkswap in some way to handle this gracefully. For example, mkswap could learn a new switch --idempotent or so, which we could always pass from systemd. If set and if activating the swap fails with EBUSY because the swap is already activated it would eat that up and return success. I implemented a different logic now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=37cf8fee46025d704660a9fc1d1349fe7d0b139d With this change we'll now dispatch only one mkswap per device node, regardless which symlinked alias is used to refer to it. I have only given this very light testing, and I am not sure this solves the original problem you reported, hence I'd be thankful if you could check if this makes the problem go away. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Tue, 27.01.15 23:40, Lennart Poettering (lenn...@poettering.net) wrote: On Tue, 27.01.15 23:31, Lennart Poettering (lenn...@poettering.net) wrote: On Fri, 23.01.15 10:18, Martin Pitt (martin.p...@ubuntu.com) wrote: So perhaps the more robust fix would be to make the gpt generator not generate swap units if fstab already configures any swap device? I. e. auto-discovery and swaps in fstab are mutually exclusive then. Hmm, so there's something fishy here. systemd should already handle this nicely, and I thought I tested this successfully. The logic here is that when we enumerate through /proc/swaps we already check udev to not only then set the device listed in there to active, but also all .swap units that are defined by any of its symlink names. This means, activating a swap partition should result in a number of .swap devices to go active, not just one. THis is visible if you type systemctl -a -t swap, which should show a number of .device units for the same actual swap device... Now, if two jobs are queued to up a swap device, using different names for it, like an entry in fstab, and a GPT auto-discovered partition might do it, then this should mean that one of the jobs should be removed by the effect of the other, i.e. the later job should be immediately succeed, since the other job already caused the swap device to go active. There must be a bug somewhere with this... Any chance you can boot in debug mode and check how the .swap units change states during the boot, and when the jobs for it are enqueued? Hmm, thinking a bit more about this. The problem is probably this one: when the jobs are queued we cannot know that the devices they are queued by are actually the same, hence both are queued. Now, if the .device unit backing the two .swap units, both .swap units are suddenly runnable, and hence systemd forks off swapon for both of them immediately. it will then eventually see that both .swap devices are now active from /proc/swaps, but at that time it already had forked off both mkswap's, and one of them will then fail... I wonder what we can do about this. One approach could be to say that automatically discovered mounts and swaps are always dispatched before the ones from /etc/fstab. By serializing things it would be guaranteed that one of the mkswaps runs first, thus brining up both .swap units, so that the second mkswap would not be done, since the .swap would already be up... That said, it would of course be nicer if we wouldn't have to serialize here... Another idea might be to simply accept that activating the swap by two names at the same time can happen concurrently, and teach mkswap in some way to handle this gracefully. For example, mkswap could learn a new switch --idempotent or so, which we could always pass from systemd. If set and if activating the swap fails with EBUSY because the swap is already activated it would eat that up and return success. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Tue, 27.01.15 23:29, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 01/27/2015 10:48 PM, Lennart Poettering wrote: Another idea might be to simply accept that activating the swap by two names at the same time can happen concurrently, and teach mkswap in some way to handle this gracefully. For example, mkswap could learn a new switch --idempotent or so, which we could always pass from systemd. If set and if activating the swap fails with EBUSY because the swap is already activated it would eat that up and return success. Is not the problem here that we are using two generators to parse this? No, not at all. The problem is simply that we cannot know in advance that /dev/sda7 and /dev/disk/by-uuid/c0e7978b-f82b-4b7f-b72b-6717f6909abc will eventually refer to the same device. We hence have to enqueue jobs to activate both, but finally, when the device actually appears and we realize both names actually refer to the same device, we need to handle this gracefully, instead of actually invoking mkswap on both of them. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Tue, Jan 27, 2015 at 5:05 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 27.01.15 23:29, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 01/27/2015 10:48 PM, Lennart Poettering wrote: Another idea might be to simply accept that activating the swap by two names at the same time can happen concurrently, and teach mkswap in some way to handle this gracefully. For example, mkswap could learn a new switch --idempotent or so, which we could always pass from systemd. If set and if activating the swap fails with EBUSY because the swap is already activated it would eat that up and return success. Is not the problem here that we are using two generators to parse this? No, not at all. The problem is simply that we cannot know in advance that /dev/sda7 and /dev/disk/by-uuid/c0e7978b-f82b-4b7f-b72b-6717f6909abc will eventually refer to the same device. Are these just scary looking warnings? Or is swapon actually listing the same device twice, as if it's activated twice? That'd seem to be a bug. What if the fstab listed the same swap twice, either duplicate lines or one line with /dev/sdXY and one line with UUID for the same device? I thought /dev/sdXY is considered sufficiently unreliable that it shouldn't be used for static configuration files anymore.? Patient: Doctor, when I bend my arm like this it hurts! Doctor: I suggest not bending your arm that way. It's probably not what people want to hear because it doesn't really solve the problem, but the problem is created by an unreliable practice in the first place. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Fri, 23.01.15 10:18, Martin Pitt (martin.p...@ubuntu.com) wrote: So perhaps the more robust fix would be to make the gpt generator not generate swap units if fstab already configures any swap device? I. e. auto-discovery and swaps in fstab are mutually exclusive then. Hmm, so there's something fishy here. systemd should already handle this nicely, and I thought I tested this successfully. The logic here is that when we enumerate through /proc/swaps we already check udev to not only then set the device listed in there to active, but also all .swap units that are defined by any of its symlink names. This means, activating a swap partition should result in a number of .swap devices to go active, not just one. THis is visible if you type systemctl -a -t swap, which should show a number of .device units for the same actual swap device... Now, if two jobs are queued to up a swap device, using different names for it, like an entry in fstab, and a GPT auto-discovered partition might do it, then this should mean that one of the jobs should be removed by the effect of the other, i.e. the later job should be immediately succeed, since the other job already caused the swap device to go active. There must be a bug somewhere with this... Any chance you can boot in debug mode and check how the .swap units change states during the boot, and when the jobs for it are enqueued? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Mon, Jan 26, 2015 at 10:08:02AM +0100, Martin Pitt wrote: Peter Mattern [2015-01-23 14:03 +0100]: According to man (http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html, see section Description) systemd-gpt-auto-generator is supposed to behave like this by now already. Supposed yes, but I don't see anything in gpt-auto-generator.c which would actually check fstab. The only check I see is path_is_mount_point() in probe_and_add_mount(), but as the generators all run during very early boot where most of the mounts did not happen yet, this doesn't help. What the man page really means is that if you have a units with the same name, the one from the generator will have lower priority. Unfortunately does not help at all for the case at hand. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Tue, Jan 27, 2015 at 8:19 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: You also need swap if you want to use all of your memory. If you have no swap, allocating close to 100% RAM becomes very dangerous, because any overflow will result in oom. Yes that makes sense too. Maybe zram will work out such that it effectively slows things to a craw until pressure instead of implosion, and swap on disk can mostly be obviated for the ordinary cases. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Tue, Jan 27, 2015 at 10:25:32PM -0700, Chris Murphy wrote: On Tue, Jan 27, 2015 at 8:19 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: You also need swap if you want to use all of your memory. If you have no swap, allocating close to 100% RAM becomes very dangerous, because any overflow will result in oom. Yes that makes sense too. Maybe zram will work out such that it effectively slows things to a craw until pressure instead of implosion, and swap on disk can mostly be obviated for the ordinary cases. Certainly not for all cases. zram can give compression on the order of 50% max, so it allows you to trade some CPU for RAM, but does not help at all for the case I described, since my data is noncompressible and cpus are maxed out anyway. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Tue, Jan 27, 2015 at 05:47:07PM -0700, Chris Murphy wrote: On Tue, Jan 27, 2015 at 5:28 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 01/28/2015 12:24 AM, Lennart Poettering wrote: On Tue, 27.01.15 17:17, Chris Murphy (li...@colorremedies.com) wrote: The problem is simply that we cannot know in advance that /dev/sda7 and /dev/disk/by-uuid/c0e7978b-f82b-4b7f-b72b-6717f6909abc will eventually refer to the same device. Are these just scary looking warnings? It should be unproblematic, but it looks scary right now. The swapon will only succeed once, and fail the second time, and that doesn't look pretty, but the kernel should do the right thing and not get confused by this. I can confirm it does and I simply remove the swap entry in fstab to make it go away when I encountered it. That said are there any real practical benefits of using swap et al in today's age or are people just still creating it out of habit? For those who have hibernation working, it's needed. And there's a case for it on baremetal servers, it's sometimes better that they slow down instead of totally face planting. And it can be useful if you don't have enough memory to do a full fsck on a large file system, especially if swap is on an SSD it's not as slow as on a HDD. But otherwise, maybe not. You also need swap if you want to use all of your memory. If you have no swap, allocating close to 100% RAM becomes very dangerous, because any overflow will result in oom. If you have swap configured, it acts as a safety valve. For example, I have servers with long-running simulations where the amount of memory used tailored to the task, and 95% of memory is used. If I logged into this machine and run the package manager, without swap, the kernel would start killing off the jobs. Zbyszek Over on that other OS that begins with W, it looks like they aren't using swap directly. Instead there's a separate Intel Rapid Start specific partition (it has it's own GPT partition type GUID) that puts some kind of hibernation like file there on normal shutdown. Cold boot times are insanely fast, like 3-4 seconds from pushing the button. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
Peter Mattern [2015-01-23 14:03 +0100]: According to man (http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html, see section Description) systemd-gpt-auto-generator is supposed to behave like this by now already. Supposed yes, but I don't see anything in gpt-auto-generator.c which would actually check fstab. The only check I see is path_is_mount_point() in probe_and_add_mount(), but as the generators all run during very early boot where most of the mounts did not happen yet, this doesn't help. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Swap gets activated twice (through fstab and gpt generators)
Hello all, we just received a report (https://launchpad.net/bugs/1399595) that swap gets activated twice: | systemd[1]: Activating swap Swap Partition... | systemd[1]: Activating swap /dev/disk/by-uuid/73d341f1-eedc-43fc-9e53-ba4194dae3fb... | swapon[396]: swapon: /dev/disk/by-uuid/73d341f1-eedc-43fc-9e53-ba4194dae3fb: swapon failed: Device or resource busy | systemd[1]: dev-disk-by\x2duuid-73d341f1\x2deedc\x2d43fc\x2d9e53\x2dba4194dae3fb.swap swap process exited, code=exited status=255 | systemd[1]: Failed to activate swap /dev/disk/by-uuid/73d341f1-eedc-43fc-9e53-ba4194dae3fb. | systemd[1]: Unit dev-disk-by\x2duuid-73d341f1\x2deedc\x2d43fc\x2d9e53\x2dba4194dae3fb.swap entered failed state. | systemd[1]: Activated swap Swap Partition. | kernel: Adding 8298492k swap on /dev/sda3. Priority:-1 extents:1 across:8298492k SSFS It turns out that the fstab and the gpt generator are overlapping here. gpt creates a unit dev-sda3.swap: | # Automatically generated by systemd-gpt-auto-generator | | [Unit] | Description=Swap Partition | Documentation=man:systemd-gpt-auto-generator(8) | | [Swap] | What=/dev/sda3 | /tmp/r/tmp/gpt/dev-sda3.swap (END) while /etc/fstab has | # sda3 | UUID=73d341f1-eedc-43fc-9e53-ba4194dae3fb none swap sw 0 0 and thus the fstab generator creates one for the UUID name dev-disk-by\x2duuid-73d341f1\x2deedc\x2d43fc\x2d9e53\x2dba4194dae3fb.swap: | # Automatically generated by systemd-fstab-generator | | [Unit] | SourcePath=/etc/fstab | Documentation=man:fstab(5) man:systemd-fstab-generator(8) | | [Swap] | What=/dev/disk/by-uuid/73d341f1-eedc-43fc-9e53-ba4194dae3fb | Options=sw Thus we get two units for the same swap device, and worse, the gpt one won over the fstab one (just by sheer chance, this is a race). So this is a bit tricky; obviously both units are justified: we want the auto-discovery in gpt, and enable swap from fstab without GPT. One idea would be to resolve symlinks after the generators (in particular fstab) discovered the device names. Then fstab would also create a dev-sda3.swap, and that unit would override the one generated by gpt. As fstab should always win over gpt (as you might have additional options there), gpt should write into .late and fstab into early or normal? There is a potential problem, though: at the time when the generator runs, the device might not exist yet; it might take longer to be detected, or it's on LVM or behind a still locked LUKS etc. In that case the /dev/disks/... link doesn't even exist yet and we can't resolve it. So perhaps the more robust fix would be to make the gpt generator not generate swap units if fstab already configures any swap device? I. e. auto-discovery and swaps in fstab are mutually exclusive then. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
I saw this on an Arch Linux (systemd 218) i686 QEMU VM using BIOS and GPT, too. Couldn't see it on another x86_64 VM using UEFI (TianoCore / OVMF) and GPT but configured exactly the same apart from this. Lenovo's Yoga 2 Pro used by the said bug report's OP is featuring a BIOS, too. So perhaps the more robust fix would be to make the gpt generator not generate swap units if fstab already configures any swap device? I. e. auto-discovery and swaps in fstab are mutually exclusive then. According to man (http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html, see section Description) systemd-gpt-auto-generator is supposed to behave like this by now already. So maybe a bug in systemd-gpt-auto-generator manifesting only in the context of BIOS + GPT? Regards, Peter Mattern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
