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/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 =
>>> Andrei Borzenkov schrieb am 13.08.2020 um 09:05 in
Nachricht <0ae86394-3dc0-71cf-818f-d746ba5de...@gmail.com>:
> 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
>>>
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
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,
> >>>
eOn Do, 13.08.20 09:24, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) 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.
>
> Especially as
>>> Lennart Poettering schrieb am 13.08.2020 um 11:13
in
Nachricht <20200813091301.GF229811@gardel-login>:
> eOn Do, 13.08.20 09:24, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
> wrote:
>
>> > systemd should really clearly log this (invalid PID and and in which
>> > cgroup it was).
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
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 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 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
Hello David.
On Tue, Aug 11, 2020 at 02:33:11PM +1200, David Cunningham
wrote:
> The problem is most likely with systemd thinking the program is stopped
> because "systemctl status" reports:
> Aug 10 03:57:32 myhost systemd[1]: product_routed.service: Main process
> exited, code=exited,
Hello,
I have some questions regarding system freezing at boot after activating EVM. I
receive this error message:
systemd[1]: Failed to mount cgroup at /sys/fs/cgroup/system: No such file
of device.
[!] Failed to mount API filesystems, freezing.
I am using Linux kernel
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
Hi,
Thanks for the updates about systemd-inhibit!
It will be a great enhancement.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
16 matches
Mail list logo
