LXC Container stuck on startup, hangs pveproxy

alexskysilk said:
Not really. there is a substantial difference in the fault; namely that the hung process in @denos situation is recoverable. In my scenario the lxc process is a zombie and cannot be killed. while both setups utilize kernel modules to access the storage, I dont know if this particular issue is specific to ceph (me), zfs (denos) or kernel specific...
Click to expand...

I saw the reference and wanted to add some clarification: the issue in my thread is a kernel bug and has been unrecoverable in my experience (waiting up to 3 days). The hypervisor has to be rebooted once the namespace cloning bug is hit. The issue has a distinctive stack trace on lxc monitor processes which always contains copy_net_ns. Based on your stack trace (without copy_net_ns) I believe your issue is unrelated.
 
Updating to Kernel version 4.15-3-pve definitely has an impact, but did not fix the problem. vzdump continues to get stuck but at least the instability behavior appears to be gone. will update this thread if/when there is additional information to add.
 
What about this one?
Code: 
# strace lxc-stop -n 110 --kill
...
read(10, "lxc.hook.pre-start = /usr/share/"..., 4096) = 190
read(10, "", 4096)                      = 0
close(10)                               = 0
munmap(0x7f9dc41c9000, 4096)            = 0
getdents(9, /* 0 entries */, 32768)     = 0
close(9)                                = 0
read(8, "", 4096)                       = 0
close(8)                                = 0
munmap(0x7f9dc41ca000, 4096)            = 0
read(7, "", 4096)                       = 0
close(7)                                = 0
munmap(0x7f9dc41cb000, 4096)            = 0
open("/dev/urandom", O_RDONLY)          = 7
fstat(7, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0
ioctl(7, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7ffe121ae1e0) = -1 EINVAL (Invalid argument)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9dc41cb000
read(7, "\364T\354t\370 >\24\261\335\343\375\36Z\366f\316aN\277\345\336u*\273(\215\251p\362Q;"..., 4096) = 4096
close(7)                                = 0
munmap(0x7f9dc41cb000, 4096)            = 0
open("/dev/urandom", O_RDONLY)          = 7
fstat(7, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0
ioctl(7, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7ffe121ae1c0) = -1 EINVAL (Invalid argument)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9dc41cb000
read(7, "rF\224~\253\201S\f\t)\246\316\301(\205D\206\203\250\342* aW\254|\245xJ\306>1"..., 4096) = 4096
close(7)                                = 0
munmap(0x7f9dc41cb000, 4096)            = 0
read(6, "", 4096)                       = 0
close(6)                                = 0
munmap(0x7f9dc41cc000, 4096)            = 0
fcntl(5, F_SETLK, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
close(5)                                = 0
stat("/var/lib/lxc/110/partial", 0x7ffe121ae460) = -1 ENOENT (No such file or directory)
socket(PF_LOCAL, SOCK_STREAM, 0)        = 5
connect(5, {sa_family=AF_LOCAL, sun_path=@"/var/lib/lxc/110/command"}, 27) = 0
getuid()                                = 0
getgid()                                = 0
sendmsg(5, {msg_name(0)=NULL, msg_iov(1)=[{"\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16}], msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS{pid=25971, uid=0, gid=0}}, msg_flags=0}, MSG_NOSIGNAL) = 16
recvmsg(5,

There it hangs.
Also already persists for several days. Other containers keep running fine.
Running kernel 4.4.98-4-pve
 
You must log in or register to reply here.
Top Bottom