I have no idea what is causing this, but we've definately seen this.
** Changed in: lxc (Ubuntu)
Importance: Undecided => High
** Changed in: lxc (Ubuntu)
Status: New => Confirmed
** Also affects: upstart (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug
More simply, in a wily upstart container based on the cloud images tasks
are killed right off the bat:
lxc start w1; lxc exec w1
# ps
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/153061
ubuntu@upstart:~$ sudo lxc-start -n cloud1; sudo lxc-attach -n cloud1
root@cloud1:~# ps -ef
UIDPID PPID C STIME TTY TIME CMD
root 1 0 0 04:55 ?00:00:00 /sbin/init
root99 0 0 04:55 pts/000:00:00 /bin/bash
root 117 1 0 04:55 ?
(Where the last prompt comes from the lxc-attach having been killed)
stopping lxcfs on the host prevents this from happening.
I don't think lxcfs is to blame, though but rather fuse.
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notificat
An strace of the attach shows:
15047 read(0,
15047 +++ killed by SIGKILL +++
15033 <... wait4 resumed> [{WIFSIGNALED(s) && WTERMSIG(s) == SIGKILL}], 0,
NULL) = 15047
15033 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=15047,
si_uid=0, si_status=SIGKILL, si_utime=2, si_stime=1} ---
I'm seeing a direct correlation here between the symptom and the kernel
emitting uevents. For example, in the host run:
$ udevadm --monitor
And in another terminal in the host run:
# losetup /dev/loop0 foo
This causes the symptoms even though it has no direct impact on the
container, but does
Thanks for looking into it. Are there any downsides to disabling udev in
the container (by removing /etc/init/udev.conf for example) if we don't
need the container to be notified of new devices?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscri
Quoting Shimin (shi...@databricks.com):
> Thanks for looking into it. Are there any downsides to disabling udev in
> the container (by removing /etc/init/udev.conf for example) if we don't
> need the container to be notified of new devices?
hi, no this should have no downsides. You can just
echo