[systemd-devel] [PATCH] Fix starting swap unit on symlink made it unstoppable

jjacky i.am.jack.mail at gmail.com
Tue Oct 23 13:15:00 PDT 2012


On 10/23/12 21:05, Lennart Poettering wrote:
> On Sat, 13.10.12 14:24, Olivier Brunel (i.am.jack.mail at gmail.com) wrote:
> 
>> Starting a swap unit pointing to (What) a symlink (e.g. /dev/mapper/swap
>> or /dev/disk/by-uuid/...) would have said unit be marked active, follow
>> the one using the "actual" device (/dev/{dm-1,sda3}), but that new unit
>> would be seen as inactive.
>> Since all requests to stop swap units would follow/redirect to it,
>> and it is seen inactive, nothing would be done (swapoff never called).
>>
>> This is because this unit would be treated twice in
>> swap_process_new_swap, the second call to swap_add_one causing it to
>> eventually be marked inactive.
>>
>> Signed-off-by: Olivier Brunel <i.am.jack.mail at gmail.com>
>> ---
>> The patch removes the call to udev_device_get_devnode, assuming that
>> device nodes (and not symlinks) are used under /proc/swaps, which
>> seems to be the case.
> 
> This is not the case on Fedora at least.

Oh? I assumed it would be more of a kernel thing, so likely to be the
same everywhere. Also, a quick test in a VM running FC17, when I enable
a swap on /dev/mapper/foo it gets listed as /dev/dm-2 under /proc/swaps,
aka where the symlink points to.
Anyhow...

> 
> swap.c really needs to handle "following" devices properly (see other
> mail). We cut some corners there, and we shouldn't.

Does that mean keeping the call to udev_device_get_devnode and simply
using strcmp to make sure the same unit isn't processed twice (which
causes the bug) isn't enough?

At least AFAICS it does fix the bug, and the "following" seems to be
working fine.

-j

> 
> Lennart
> 


More information about the systemd-devel mailing list