Summary: | [container] telinit from systemd-sysvinit re-execs itself in a non-stop loop | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Stanislav Levin <slev> |
Component: | systemd-sysvinit | Assignee: | Alexey Shabalin <shaba> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | critical | ||
Priority: | P5 | CC: | arseny, at, glebfm, imz, iv, ldv, placeholder, rider, shaba, vseleznv, vt |
Version: | unstable | ||
Hardware: | x86_64 | ||
OS: | Linux |
Description
Stanislav Levin
2021-12-20 18:07:54 MSK
(In reply to Stanislav Levin from comment #0) > [root@acaa6cfff02e /]# ps -auxfww > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > root 1 0.0 0.0 3912 3324 pts/0 Ss 11:27 0:00 /bin/bash > root 88 0.4 0.9 164324 156396 pts/0 T 11:31 0:06 apt-get > install -y systemd > root 378 0.0 0.0 3316 2552 pts/0 T 11:31 0:00 \_ > /bin/sh -e /usr/lib/rpm/posttrans-filetriggers > /var/lib/rpm/files-awaiting-filetriggers > root 380 0.0 0.0 3316 2616 pts/0 T 11:31 0:00 \_ > /bin/sh -e /usr/lib/rpm/0ldconfig.filetrigger > root 383 0.2 0.0 1448 4 pts/0 T 11:31 0:03 > \_ /sbin/telinit u Something has stopped the whole thing, that's wrong. > so, previously /sbin/telinit pointed to sysvinit, but it was also called > (wrongly?). Why wrongly? It was placed there for a reason. > Probably, it's safer to skip the telinit call if a system wasn't booted with > sysvinit or systemd. It's telinit job to handle this. so, you think systemctl should handle this case, right? (In reply to Stanislav Levin from comment #2) > so, you think systemctl should handle this case, right? If systemd provides telinit, it should behave like telinit, shouldn't it? By the way, what's acting as init in this container? (Ответ для Dmitry V. Levin на комментарий #3) > (In reply to Stanislav Levin from comment #2) > > so, you think systemctl should handle this case, right? > > If systemd provides telinit, it should behave like telinit, shouldn't it? Could you please reassign the bug to systemd then? > By the way, what's acting as init in this container? In provided example /bin/bash is acting as pid 1. (In reply to Stanislav Levin from comment #4) > (Ответ для Dmitry V. Levin на комментарий #3) > > (In reply to Stanislav Levin from comment #2) > > > so, you think systemctl should handle this case, right? > > > > If systemd provides telinit, it should behave like telinit, shouldn't it? > > Could you please reassign the bug to systemd then? Reproduced in hasher: $ hsh-run --root -- timeout 0.1 strace -eexecve telinit u execve("/sbin/telinit", ["telinit", "u"], 0x7ffe3d1e4330 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffd32ae6a00 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffda6153f90 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffdb0d58280 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffc03cb3ad0 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffc71e01e40 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffd4d03e810 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffc5e59b6b0 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffda4b30d80 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffca9b2abc0 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffdb60e9560 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffd36c63470 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffe3f4805a0 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7fff735174f0 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffdb8e0b9e0 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7fff1b717550 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffc684f03d0 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffcd79f8320 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffef41f7b90 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffff288b820 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffe6e80b3e0 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffc88851750 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffea8255220 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffc02a0a380 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffcb67c9ca0 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffde790b570 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7fff93985920 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffee96acc40 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffe8fd0d9b0 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffea7459c20 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7fff99dc7da0 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffd7815cb90 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffd3d49c9c0 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffe7e300e10 /* 11 vars */) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7fff0f39d4a0 /* 11 vars */) = 0 strace: Process 1807312 detached $ hsh-run --root -- timeout 0.1 strace -bexecve telinit u execve("/sbin/telinit", ["telinit", "u"], 0x7fffc6764c08 /* 11 vars */) = 0 ... faccessat2(AT_FDCWD, "/run/systemd/system/", F_OK, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory) newfstatat(AT_FDCWD, "/proc/1/root", 0x7ffeaebebd90, 0) = -1 ENOENT (No such file or directory) prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=4*1024, rlim_max=4*1024}) = 0 prlimit64(0, RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}, NULL) = 0 execve("/sbin/telinit", ["telinit", "u"], 0x7ffeaebec0f0 /* 11 vars */ <detached ...> A workaround in rpm for the faulty telinit: https://git.altlinux.org/people/ldv/packages/?p=rpm.git;a=commitdiff;h=1f2fe8b68b9dcf2a46feb5891f1986ce7bca48e5 Completely untested. (Ответ для Dmitry V. Levin на комментарий #6) > A workaround in rpm for the faulty telinit: > https://git.altlinux.org/people/ldv/packages/?p=rpm.git;a=commitdiff; > h=1f2fe8b68b9dcf2a46feb5891f1986ce7bca48e5 > Completely untested. This works for my case. |