Hi Felipe,
Felipe Sateler wrote:
> > > Upstream asks if cgroup is in v2-mode in the affected systems.
> With `findmnt -R /sys/fs/cgroup`. It should list controllers in the cgroup
> or cgroup2 filesystems.
root@lorenz:~# findmnt -R /sys/fs/cgroup
TARGET SOURCE FSTYPE
> This currently looks like this now (after I have uninstalled
> cgroupfs-mount):
>
> → findmnt -R /sys/fs/cgroup
> TARGET SOURCE FSTYPE OPTIONS
> /sys/fs/cgroup tmpfs tmpfs rw,nosuid,nodev,noexec,mode=755
> ├─/sys/fs/cgroup/unified cgroup2 cgroup2
>
Hi Felipe,
Felipe Sateler wrote:
> > > Upstream asks if cgroup is in v2-mode in the affected systems.
> >
> > How do I recognize this? I have no idea of how to check that.
>
> With `findmnt -R /sys/fs/cgroup`. It should list controllers in the cgroup
> or cgroup2 filesystems.
Thanks!
This
Hi Felipe,
Felipe Sateler wrote:
> Upstream asks if cgroup is in v2-mode in the affected systems.
How do I recognize this? I have no idea of how to check that.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer,
On Mon, Feb 4, 2019 at 11:34 AM Axel Beckert wrote:
> Hi Felipe,
>
> Felipe Sateler wrote:
> > Upstream asks if cgroup is in v2-mode in the affected systems.
>
> How do I recognize this? I have no idea of how to check that.
>
With `findmnt -R /sys/fs/cgroup`. It should list controllers in the
On Sun, Feb 3, 2019 at 6:41 PM Felipe Sateler wrote:
> Control: forwarded -1 https://github.com/systemd/systemd/issues/11645
>
> I have forwarded the bug upstream, and proposed two solutions. If upstream
> likes one, we can apply that in the debian package.
>
>
Upstream asks if cgroup is in
Processing control commands:
> forwarded -1 https://github.com/systemd/systemd/issues/11645
Bug #918764 [udev] udev: "udevadm control --reload-rules" kills all processes
except init
Set Bug forwarded-to-address to
'https://github.com/systemd/systemd/issues/11645'.
--
918764:
Control: forwarded -1 https://github.com/systemd/systemd/issues/11645
I have forwarded the bug upstream, and proposed two solutions. If upstream
likes one, we can apply that in the debian package.
Saludos
Hi Nicolas,
Nicolas Cavallari wrote:
> udev is started in rcS.d, way before elogind, which is in rc2.d.
>
> The result is that, at boot, udev clearly logs that it does
> not detect cgroups, so it will not make its sigkilling spree.
>
> But after elogind is started, the cgroups are created.
>
On 03/02/2019 13:32, Axel Beckert wrote:
> Hi Nicolas!
>
> Nicolas Cavallari wrote:
>> I do not have cgroupsfs-mount installed, but i have elogind.
>
> Interesting. I have elogind installed, too, and I also have that
> mountpoint at /sys/fs/cgroup/elogind, but nevertheless, uninstalling
>
Hi Nicolas!
Nicolas Cavallari wrote:
> I do not have cgroupsfs-mount installed, but i have elogind.
Interesting. I have elogind installed, too, and I also have that
mountpoint at /sys/fs/cgroup/elogind, but nevertheless, uninstalling
cgroupfs-mount sufficed for me. IIRC I didn't do a reboot
Package: udev
Version: 240-5
Followup-For: Bug #918764
I do not have cgroupsfs-mount installed, but i have elogind.
It apparently mounts /sys/fs/cgroup/unified, so this is enough for
udev to think it is under systemd.
A typical /proc/self/cgroup is :
1:name=elogind:/
0::/
So it is my
Hi Felipe,
thanks for looking into this.
I've made a very quick test of the patch you provided this morning,
patching systemd 240-5 source
and rebuilding the whole thing.
It works for me.
Lorenz
On Wed, Jan 30, 2019 at 7:47 PM Axel Beckert wrote:
> Hi Felipe,
>
> a short reply with that information I can gather without much effort:
>
> Felipe Sateler wrote:
> > > But we also had reports where this happend
> > > with systemd, so this doesn't seem to be depend on the init system (at
> > >
Hi Felipe,
a short reply with that information I can gather without much effort:
Felipe Sateler wrote:
> > But we also had reports where this happend
> > with systemd, so this doesn't seem to be depend on the init system (at
> > most at the init system's default features) and hence also the
On Tue, Jan 29, 2019 at 9:39 PM Axel Beckert wrote:
>
> Then I uninstalled not all of them at once but each of them one by
> one. And the one after whose purging
>
> # service udev restart
> # udevadm control --reload-rules
>
> didn't kill my processes anymore was cgroupfs-mount.
>
> So for some
Hi,
Il giorno mer 30 gen 2019 alle ore 11:26 Axel Beckert ha
scritto:
> >His "Actually I'm wrong on this" mail
> >(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918764#127) was
> >(and actually still is) confusing me.
>
I'm wrong on the claim that, for example, i can crash a VT session by
Processing control commands:
> severity -1 critical
Bug #918764 [udev] udev: "udevadm control --reload-rules" kills all processes
except init
Severity set to 'critical' from 'important'
> found -1 239-8
Bug #918764 [udev] udev: "udevadm control --reload-rules" kills all processes
except init
Control: severity -1 important
I'm downgrading this to non-RC, as I'm not convinced this is actually a
bug in udev
Am 15.01.19 um 09:08 schrieb Axel Beckert:
> Control: found -1 239-15
>
> Hi Michael,
>
> Michael Biebl wrote:
>> Am 12.01.19 um 01:02 schrieb Axel Beckert:
>>> Control: reopen
Processing control commands:
> severity -1 important
Bug #918764 [udev] udev: "udevadm control --reload-rules" kills all processes
except init
Severity set to 'important' from 'critical'
--
918764: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918764
Debian Bug Tracking System
Contact
Control: found -1 239-15
Hi Michael,
Michael Biebl wrote:
> Am 12.01.19 um 01:02 schrieb Axel Beckert:
> > Control: reopen -1
> > Control: found -1 240-3
>
> > *sigh* I'm sorry to say, but it just happened again with udev 240-3
> > and kernel 4.20-1~exp1.
>
> Would be good to know, if it also
Processing control commands:
> found -1 239-15
Bug #918764 [udev] udev: "udevadm control --reload-rules" kills all processes
except init
Marked as found in versions systemd/239-15.
--
918764: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918764
Debian Bug Tracking System
Contact
On Sat, 12 Jan 2019 14:54:09 +0100 Axel Beckert wrote:
> I don't have local access to the affected machine for the weekend and
> hence won't be able to test reboots before Monday again, though.
>
> I'm though also keen to know if a downgrade to udev 239 will make it
> more stable again, so I'll
Hi Michael,
Michael Biebl wrote:
> Please also tar up /etc/udev/rules.d and /lib/udev/rules.d and attach it
> to the bug report.
Attached.
I don't have local access to the affected machine for the weekend and
hence won't be able to test reboots before Monday again, though.
I'm though also keen
Please also tar up /etc/udev/rules.d and /lib/udev/rules.d and attach it
to the bug report.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Am 12.01.19 um 01:02 schrieb Axel Beckert:
> Control: reopen -1
> Control: found -1 240-3
> *sigh* I'm sorry to say, but it just happened again with udev 240-3
> and kernel 4.20-1~exp1.
Would be good to know, if it also happens with 239-15 or if it's caused
by some other update.
Tbh, udevd or
Processing control commands:
> reopen -1
Bug #918764 {Done: Axel Beckert } [udev] udev: "udevadm
control --reload-rules" kills all processes except init
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Control: reopen -1
Control: found -1 240-3
Hi Michael,
Michael Biebl wrote:
> > I luckily can no more reproduce this with udev 240-3 and kernel
> > 4.19.13-1 or 4.20-1~exp1.
>
> Ok, thanks for testing.
*sigh* I'm sorry to say, but it just happened again with udev 240-3
and kernel 4.20-1~exp1.
On Thu, 10 Jan 2019 06:55:32 +0100 Axel Beckert wrote:
> Version: 240-3
>
> Hi Michael,
>
> I luckily can no more reproduce this with udev 240-3 and kernel
> 4.19.13-1 or 4.20-1~exp1.
Ok, thanks for testing.
> Since I can no more reproduce this with the versions above and I'm
> also affected
Am 09.01.19 um 07:32 schrieb Axel Beckert:
> Package: udev
> Version: 240-2
Is this specific to version 240-2?
Could you try downgrading udev to either 239-15 or 240-1 and report back
with the results.
Thanks,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
Hi Michael,
thanks for having looked into it.
Michael Biebl wrote:
> I can't reproduce this problem.
Ok, good to know that it doesn't seem to affect more or less standard
installations.
So I wonder what part of my setup causes this:
* 2x LVM on LUKS on MD RAID1 (2 spinning HDDs and 2 SSDs)
*
Processing control commands:
> tags -1 moreinfo unreproducible
Bug #918764 [udev] udev: "udevadm control --reload-rules" kills all processes
except init
Added tag(s) moreinfo and unreproducible.
--
918764: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918764
Debian Bug Tracking System
Control: tags -1 moreinfo unreproducible
Am 09.01.19 um 11:16 schrieb Axel Beckert:
> Hi,
>
> Axel Beckert wrote:
>> I have no idea why this is happening, but several packages use "udevadm
>> control --reload-rules" in their postinst (e.g. fuse) and if that's run,
>> all process except init are
Hi,
Axel Beckert wrote:
> I have no idea why this is happening, but several packages use "udevadm
> control --reload-rules" in their postinst (e.g. fuse) and if that's run,
> all process except init are instantly killed (reproducibly; the gettys
> seem to be respawned by init then, so I can login
Package: udev
Version: 240-2
Severity: critical
Justification: Breaks whole system
Hi,
I have no idea why this is happening, but several packages use "udevadm
control --reload-rules" in their postinst (e.g. fuse) and if that's run,
all process except init are instantly killed (reproducibly; the
35 matches
Mail list logo
