double swap space usage

This reminds me bug #86234 but it's with kernel 2.6.20-13 (version of kernel image packe on i386 is 2.6.20-13.21).

Please attach (do not paste inline) these files:

/etc/fstab
/boor/grub/menu.lst

Please attach (do not paste inline) the output of these commands:

dmesg > dmesg.txt
sudo fdisk -l > fdisk.txt

Here you are. Strange 'netfilter' lines in dmesg is caused by '-j LOG --log-prefix ...' rules set by iptables.

Ok, that was on my AMD64 box, here is files from an i386 one.

The only thing I noticed is that the initrd in the AMD64 menu.lst is incorrect.

Is it? Where? However please note, that this affect *all* of the tested macnines running feisty, an AMD64 box, and at least three i386 ones.

On your AMD64 machine the initrd line in /boot/grub/menu.lst is 'initrd /boot/initrd.img'. Normally it ought to be 'initrd /initrd.img-2.6.20-14-generic'. I don't know for sure if this is a problem, but it is abnormal.

Hmm, I dunno, however it makes sense for me: since the kernel image itself is also only 'vmlinuz' there, I guess it boots the 'current' kernel maintained by symlinks for kernel image and the initrd itself (at that time there was no 2.6.20-14 kernel, only 13, by the way, however I've just checked with -14, and it's the same). Also, /boot/initrd.img and /boot/vmlinuz points to the right files. But to be sure, I've just selected the 'right' entry in grub menu (which does not point the symlinks but the desired kernel image and initrd) and the problem remains. And also, this problem occured on several machines both on AMD64 and i386.

Same here with Kubuntu Feisty final i386

Performing:
sudo swapoff-a && sudo swapon -a

seems to fix the problem until next reboot.

err typo:
sudo swapoff -a && sudo swapon -a

Change can be confirmed by doing free before and after
Also by doing swapon -s

I confirm that swapoff and swapon fix the problem, but only until the next boot.

Hope to have a fix soon.

I'm sure someone has thought of this already, but I had this bug too and I edited the swap entry in my fstab to point to /dev/sda6 instead of it's UUID. Now 'free' shows the correct amount of swap. It's not exactly a fix, but it is a temporary work around until the bug is worked out.

I think this bug should be considered very serious, since on heavy swapping, use the same disk (directlty and via mapper) will cause a crash, sure. As far as I can see the problem is caused by using swap as UUID, and the same swap partition is found directly and via mapper (lvm) as well, so someone would limit the result to one of a partition identification process requested by UUID which should cure the problem. Sure, I can modify /etc/fstab to use eg /dev/sda6, or I can swapoff /dev/mapper/whatever, however it's very dangerous with default install and/or someone does not notice or don't know what can be done here ...

I'm using updates every day, but my issue remains even now:

lgb@oxygene:~$ cat /proc/swaps
Filename Type Size Used Priority
/dev/sda1 partition 1951856 200676 -1
/dev/mapper/sda1 partition 1951856 0 -2

lgb@oxygene:~$ grep swap /etc/fstab
UUID=c1f97893-2241-4284-90e9-0d792217d9a7 none swap sw 0 0

FYI, I have the same pb:
~$ cat /proc/swaps
Filename Type Size Used Priority
/dev/sda1 partition 3148700 0 -1
/dev/mapper/sda1 partition 3148700 0 -2

But I don't feel that's a kernel version matter
~$ uname -r
2.6.20-15-generic

my fstab was using /dev/hda5 for swap before i upgraded
the upgrade changed it to uuid usage(probly so it wouldnt care about the apparent scsi emulation that came out of nowhere)
the upgrade caused my hda to show as sda but it was changing back and forth at one point as i was manualy selecting kernels to fix other bugs
it was using both dev/sda5 and /dev/mapper/sda5 and ive since edited fstab to only use 1 of them so it cant happen
i know the drive is psysicaly ide based since i can plug it into a ide addapter and use it in a normal desktop pc as a parralle ide drive

Same kernel, 2.6.20-15-generic, same problem here.
Happened after sequential upgrade from dapper to edgy to feisty

~$ cat /proc/swaps
Filename Type Size Used Priority
/dev/sda5 partition 1012052 0 -1
/dev/mapper/sda5 partition 1012052 0 -2
~$ sudo swapoff -a && sudo swapon -a
Password:
~$ cat /proc/swaps
Filename Type Size Used Priority
/dev/mapper/sda5 partition 1012052 0 -3
~$

I found a way this bug can cause ugly crashes in real life. I bought a second hard drive and tried making two swaps to be used simultaneosly. That involves making the priorities fixed, and i ended up with

~$ cat /proc/swaps
Filename Type Size Used Priority
/dev/hda6 partition 1076284 0 1
/dev/sda1 partition 1052216 0 1
/dev/mapper/hda6 partition 1076284 0 1

Now both hda6-entries have same priorities and will be used at same time...

The mentioned sudo swapoff -a && sudo swapon -a fixes the problem until reboot.
And I just removed the UUID from my fstab, I hope that will work for me.

amd64, 2.6.20-15-generic, upgraded all the way from 5.04-...-7.04.

I think my fstab was like this before removing the UUID.

OK, I've removed package 'evms' and of course it fixed the problem, since I don't need evms anyway. But it's not a solution if someone needs it, I guess.

Why this bug is tagged "Won't Fix" ? From my point of view, it's a critical bug.
This bug is already fixed in the latest version of evms ?

Agreed. I think this bug is the type of most dangerous bugs, it should be fixed first and very fast, since it cause full system crash loosing data, and so. Just try to inmagine what will happens when kernel star to swap to a partition which is also used without evms and such: sure it will crash very badly. Bug in an appliaction (like a word processor etc) only affacts that software, but in our case it will crash the kernel so all running processes in the system with all important data, etc etc

Feisty is in a Stable Release Update status. Only security related changes are allowed.
See https://wiki.ubuntu.com/KernelUpdates?highlight=%28kernel%29 for the update policy.

On Feisty, I confirm that uninstalling evms solves (temporary) the pb.
"temporary", because it's still a bug.
And I still think that's no link with kernel, but I'm not a specialist.

Okay for feisty, nevertheless will this bug be fixed for 7.10 ?

Tim: Thx for explanation, I see, but it's also a security problem. On a multiuser system, someone can take a look on /proc/swaps and realizes the situation. So, (s)he starts programs to consume enough memory kernel to start to use the "second" swap partition which is actually the same but it does not know about this. The result: local user can cripple the whole system. I don't know it can be treated as security problem with this example though ... However it's true that if someone maintain a server with users on it, (s)he should know about the issue ... :)

I've subscribed our security expert who is also a member of the server team. Perhaps he can offer an opinion.

There are plenty of ways for a local user to DoS a system, so I would consider this not to be a security bug.

This bug, as already found, is a bug with evms. For Gutsy, evms has been moved out of "main" since it causes more problems than it solves. Please uninstall evms and make sure you're mounting your swap via UUID again, and everything should be fine. Please see bug 109320.