On 8/13/20 11:03 AM, Lennart Poettering wrote:
Is it possible the container and the host run in the very same cgroup
hierarchy?
If that's the case (and it looks like it): this is not
supported. Please file a bug against LXC, it's very clearly broken.
FYI:
On Fr, 14.08.20 06:42, Harald Dunkel (harald.dun...@aixigo.com) wrote:
> On 8/13/20 11:07 AM, Lennart Poettering wrote:
> >
> > No! It's a bug. Not in systemd, but LXC. But generating errors in such
> > a borked setup is *good*, not bad, and certainly nothing to hide.
> >
>
> Surely its not a bug
On 8/13/20 11:07 AM, Lennart Poettering wrote:
No! It's a bug. Not in systemd, but LXC. But generating errors in such
a borked setup is *good*, not bad, and certainly nothing to hide.
Surely its not a bug in systemd, but ignoring unreasonable data (maybe with
a warning, if necessary) has a
On Do, 13.08.20 09:20, Michael Biebl (mbi...@gmail.com) wrote:
> > >>
> > >> kernel returns "0" as process number in this cgroup which results in EIO
> > >> returned by systemd.
> > >
> >
> > systemd should really clearly log this (invalid PID and and in which
> > cgroup it was). Returning
On Do, 13.08.20 09:17, Harald Dunkel (harald.dun...@aixigo.com) wrote:
> On 8/13/20 9:05 AM, Andrei Borzenkov wrote:
> >
> > systemd should really clearly log this (invalid PID and and in which
> > cgroup it was). Returning generic error message without any indication
> > what caused this error
On Do, 13.08.20 10:05, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> 13.08.2020 09:54, Harald Dunkel пишет:
> > On 8/12/20 2:16 PM, Andrei Borzenkov wrote:
> >> 12.08.2020 14:03, Harald Dunkel пишет:
> >>> See attachment. Hope this helps
> >>> Harri
> >>
> >>
> >>> 1 openat(AT_FDCWD,
> >>>
On Do, 13.08.20 08:54, Harald Dunkel (harald.dun...@aixigo.com) wrote:
> On 8/12/20 2:16 PM, Andrei Borzenkov wrote:
> > 12.08.2020 14:03, Harald Dunkel пишет:
> > > See attachment. Hope this helps
> > > Harri
> >
> >
> > > 1 openat(AT_FDCWD,
> > >
On Do, 13.08.20 10:05, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> >>> 1 openat(AT_FDCWD,
> >>> "/sys/fs/cgroup/unified/system.slice/rsyslog.service/cgroup.procs",
> >>> O_RDONLY|O_CLOEXEC) = 24
> >>> 1 read(24, "0\n1544456\n", 4096) = 10
> >>
> >>
> >> kernel returns "0" as
Am Do., 13. Aug. 2020 um 09:05 Uhr schrieb Andrei Borzenkov
:
>
> 13.08.2020 09:54, Harald Dunkel пишет:
> > On 8/12/20 2:16 PM, Andrei Borzenkov wrote:
> >> 12.08.2020 14:03, Harald Dunkel пишет:
> >>> See attachment. Hope this helps
> >>> Harri
> >>
> >>
> >>> 1 openat(AT_FDCWD,
> >>>
On 8/13/20 9:05 AM, Andrei Borzenkov wrote:
systemd should really clearly log this (invalid PID and and in which
cgroup it was). Returning generic error message without any indication
what caused this error is not useful at all.
Do you think it would be reasonable to silently ignore the PID =
13.08.2020 09:54, Harald Dunkel пишет:
> On 8/12/20 2:16 PM, Andrei Borzenkov wrote:
>> 12.08.2020 14:03, Harald Dunkel пишет:
>>> See attachment. Hope this helps
>>> Harri
>>
>>
>>> 1 openat(AT_FDCWD,
>>> "/sys/fs/cgroup/unified/system.slice/rsyslog.service/cgroup.procs",
>>>
On 8/12/20 2:16 PM, Andrei Borzenkov wrote:
12.08.2020 14:03, Harald Dunkel пишет:
See attachment. Hope this helps
Harri
1 openat(AT_FDCWD,
"/sys/fs/cgroup/unified/system.slice/rsyslog.service/cgroup.procs",
O_RDONLY|O_CLOEXEC) = 24
1 read(24, "0\n1544456\n", 4096)= 10
12.08.2020 14:03, Harald Dunkel пишет:
> See attachment. Hope this helps
> Harri
> 1 openat(AT_FDCWD,
> "/sys/fs/cgroup/unified/system.slice/rsyslog.service/cgroup.procs",
> O_RDONLY|O_CLOEXEC) = 24
> 1 read(24, "0\n1544456\n", 4096)= 10
kernel returns "0" as process number in
On Mi, 12.08.20 13:03, Harald Dunkel (harald.dun...@aixigo.com) wrote:
> 1 getuid() = 0
> 1 kill(1544456, SIGHUP) = 0
So, first, systemd tries and succeeds to kill the main process of your
service with SIGHUP. So far far so good.
> 1
On 8/12/20 1:03 PM, Harald Dunkel wrote:
See attachment. Hope this helps
Harri
PS:
# ls -al /sys/fs/cgroup/unified/system.slice/rsyslog.service
total 0
drwxr-xr-x 2 root root 0 Jun 20 17:40 .
drwxr-xr-x 53 root root 0 Aug 12 13:30 ..
-r--r--r-- 1 root root 0 Aug 12 13:05 cgroup.controllers
See attachment. Hope this helps
Harri
1 epoll_wait(4, [{EPOLLIN, {u32=3589379376, u64=94720503158064}}], 36, -1)
= 1
1 clock_gettime(CLOCK_BOOTTIME, {tv_sec=4562316, tv_nsec=425983895}) = 0
1 recvmsg(29, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="WATCHDOG=1\n",
12.08.2020 13:04, Harald Dunkel пишет:
> On 8/12/20 10:32 AM, Ulrich Windl wrote:
>>
>> As you found out the details already, maybe you could have added some
>> strace
>> output, especially after the kill() is returning...
>>
>
> See attachment. Hope this helps
Not really. We already know that
On 8/12/20 10:32 AM, Ulrich Windl wrote:
As you found out the details already, maybe you could have added some strace
output, especially after the kill() is returning...
See attachment. Hope this helps
Harri
44504 execve("/bin/systemctl", ["systemctl", "kill", "-s", "HUP",
18 matches
Mail list logo
