Public bug reported:
Binary package hint: kvm
Description: Ubuntu 8.10
Release: 8.10
kvm:
Installed: 1:72+dfsg-1ubuntu6
Candidate: 1:72+dfsg-1ubuntu6
In an Ubuntu guest running in kvm, the kill(2) call behaves incorrectly.
Here is an example Python session which demonstrates the misbehavior:
r...@bigdogvm1:~# python
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, threading, time
>>> os.getpid()
6894
>>> filter(str.isdigit, os.listdir('/proc'))
['1', '2', '3', '4', '5', '6', '7', '8', '9', '10', '11', '46', '47', '50',
'51', '103', '137', '138', '139', '180', '181', '1428', '1429', '1431', '1436',
'1439', '1440', '1444', '2412', '2616', '2920', '3806', '4138', '4139', '4195',
'4196', '4199', '4204', '4207', '4382', '4401', '4432', '4433', '4473', '4498',
'4546', '4548', '4570', '4586', '4600', '4613', '4635', '4656', '4657', '4694',
'4729', '4757', '5167', '5186', '5190', '5262', '5271', '5277', '5297', '5304',
'5305', '5317', '5319', '5323', '5360', '5361', '5367', '5406', '5420', '5504',
'5512', '5789', '5802', '6553', '6555', '6556', '6559', '6871', '6894']
>>> threading.Thread(target=time.sleep, args=(600,)).start()
>>> filter(str.isdigit, os.listdir('/proc'))
['1', '2', '3', '4', '5', '6', '7', '8', '9', '10', '11', '46', '47', '50',
'51', '103', '137', '138', '139', '180', '181', '1428', '1429', '1431', '1436',
'1439', '1440', '1444', '2412', '2616', '2920', '3806', '4138', '4139', '4195',
'4196', '4199', '4204', '4207', '4382', '4401', '4432', '4433', '4473', '4498',
'4546', '4548', '4570', '4586', '4600', '4613', '4635', '4656', '4657', '4694',
'4729', '4757', '5167', '5186', '5190', '5262', '5271', '5277', '5297', '5304',
'5305', '5317', '5319', '5323', '5360', '5361', '5367', '5406', '5420', '5504',
'5512', '5789', '5802', '6553', '6555', '6556', '6559', '6871', '6894']
>>> os.listdir('/proc/6895')
['task', 'fd', 'fdinfo', 'environ', 'auxv', 'status', 'limits', 'sched',
'cmdline', 'stat', 'statm', 'maps', 'mem', 'cwd', 'root', 'exe', 'mounts',
'mountstats', 'clear_refs', 'smaps', 'attr', 'wchan', 'cpuset', 'cgroup',
'oom_score', 'oom_adj', 'loginuid', 'coredump_filter', 'io']
>>> os.kill(6895, 0)
>>> os.listdir('/proc/6895')
['task', 'fd', 'fdinfo', 'environ', 'auxv', 'status', 'limits', 'sched',
'cmdline', 'stat', 'statm', 'maps', 'mem', 'cwd', 'root', 'exe', 'mounts',
'mountstats', 'clear_refs', 'smaps', 'attr', 'wchan', 'cpuset', 'cgroup',
'oom_score', 'oom_adj', 'loginuid', 'coredump_filter', 'io']
>>> os.listdir('/proc')
['scsi', 'crypto', 'key-users', 'swaps', 'kallsyms', 'dma', 'timer_stats',
'timer_list', 'iomem', 'ioports', 'sched_debug', 'misc', 'acpi', 'fb', 'mtrr',
'irq', 'cgroups', 'sys', 'bus', 'tty', 'driver', 'fs', 'sysvipc', 'net',
'sysrq-trigger', 'vmcore', 'kcore', 'modules', 'diskstats', 'zoneinfo',
'vmstat', 'pagetypeinfo', 'buddyinfo', 'slabinfo', 'interrupts', 'stat',
'partitions', 'cpuinfo', 'devices', 'locks', 'kmsg', 'mounts',
'version_signature', 'execdomains', 'cmdline', 'filesystems', 'version',
'meminfo', 'uptime', 'loadavg', 'self', '1', '2', '3', '4', '5', '6', '7', '8',
'9', '10', '11', '46', '47', '50', '51', '103', '137', '138', '139', '180',
'181', '1428', '1429', '1431', '1436', '1439', '1440', '1444', '2412', '2616',
'2920', '3806', '4138', '4139', '4195', '4196', '4199', '4204', '4207', '4382',
'4401', '4432', '4433', '4473', '4498', '4546', '4548', '4570', '4586', '4600',
'4613', '4635', '4656', '4657', '4694', '4729', '4757', '5167', '5186', '5190',
'5262', '5271', '5277', '5297', '5304', '5305', '5317', '5319', '5323', '5360',
'5361', '5367', '5406', '5420', '5504', '5512', '5789', '5802', '6553', '6555',
'6556', '6559', '6871', '6894']
>>>
This example is a bit verbose, but it shows that after creating a
thread, kill may be used to send a signal (0 in this case, not really
sending a signal, just checking to see if it is possible) to the kernel
pid of that thread (ie, its tid, I think). This behavior is incorrect.
The kill call should fail with ESRCH.
I'm not certain this is really a bug in kvm, but that seems to be what
differentiates the system where I can observe this failure from the
systems where kill works properly.
** Affects: kvm (Ubuntu)
Importance: Undecided
Status: New
--
in kvm guest, kill(2) succeeds when no process corresponds to the given PID
https://bugs.launchpad.net/bugs/341239
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
