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
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
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 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
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
Control: severity -1 critical
Control: found -1 239-8
Hi,
Gedalya wrote:
> > > Moving udev into its own special cgroup didn't change anything: udev
> > > is still running, same PID, and and the same goes for ntpd.
> > > Everything else is killed.
> >
> > And here you gave me the right hint:
On Wed, 30 Jan 2019 01:37:14 +0100 Axel Beckert wrote:
> > Moving udev into its own special cgroup didn't change anything: udev
> > is still running, same PID, and and the same goes for ntpd.
> > Everything else is killed.
>
> And here you gave me the right hint: cgroups!
>
OK, Lorenz
Control: tag -1 moreinfo
Hi!
Gedalya wrote:
> > It just happened again, triggered by wireshark-dkms
> s/wireshark/wireguard/
Ehm, yes. :-)
> Also, on my router, ntpd is moved to another cgroup (for routing
> purposes). This is done in cgroup2, old cgroup is not mounted at
> all. ntpd remains
Control: found -1 240-5
Hi again,
Axel Beckert wrote:
> Another case which predates my original bug report by a few weeks
> (week before christmas or maybe even mid-december), but which I now
> noticed that it had the exact same symptoms:
>
> I have three screens connected to my workstation:
>
On Sun, 27 Jan 2019 03:20:46 +0100 Lorenz wrote:
>
> Non-Systemd users can workaround this by using the init script from systemd
> 239-7
>
> https://salsa.debian.org/systemd-team/systemd/blob/debian/239-7/debian/udev.init
>
> or by editing the current init script replacing the --background option
> It just happened again, triggered by wireshark-dkms
s/wireshark/wireguard/
Coincidentally, I'm also using wireguard on my router. But I haven't been able
to reproduce this simply by installing wireguard and setting up a few
interfaces. Wait for the end
Also, on my router, ntpd is moved
Hi,
two more situations where this happens for me:
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 […]
It just happened again,
> >when udevd is run in background and it's not detached with it's own
> '--daemonize' option,
>
Sorry, udev option is '--daemon' , not --daemonize.
> ..Final Bonus Weirdness:
> if you start udevd in background in the VT session, then go to the
graphic
> session and prompt a udevadm command from
Hi,
I manage to reproduce this with systemd, in a Virtualbox VM.
here are the steps, after booting with systemd as init
* stop udev
# systemctl stop systemd-udevd
make sure there is no 'systemd-udevd' process list in pstree
* start udev in background like this
# setsid --fork
Hi,
With the help of snapshot.d.o, I've found that the problem first appeared in
239-8.
I've also been able to trigger it by restarting udev and running 'udevadm
control --log-priority=debug'.
Still no insight on what is the factor causing this to happen on some machines
and not on others.
Hi,
I have been experiencing this issue on my local router. First it was a virtual
machine running under KVM, with two pppoe connections, several vlans, no RAID,
no (internal) LVM. After a while I migrated the functionality to the
appropriate bare metal. I reinstalled and reconfigured from
Hi Michael, Axel
I had a system crash yesterday, during an upgrade. Udev, Grub and mdadm
were
all involved in the upgrade. The system went down during the postinst
stage, leaving
some packages uncofigured.
Even if i can't reproduce running
udevadm control --reload-rules
I think it's the same
[ More eyes is better, so please use sysvi...@packages.debian.org
instead personally me for sysvinit-related issues. I read list
carefully. ]
[2019-01-15 16:17] Axel Beckert
> Anyway, I'm taking Dmitry into Cc since sysvinit-core's init is the
> only process which survives this issue and
Am 15.01.19 um 14:28 schrieb Michael Biebl:
> This all sounds, like udevd is not the root cause of all this, tbh,
> especially since you also reproduced it with 239.
> I think "udevadm trigger" trigger something when then causes another
> component of your system to act this way.
Something, which
Hi Michael,
Michael Biebl wrote:
> Something, which seems rather obvious:
> Have you checked if your system is running out of memory and the kernel
> OOM-killer kicks in?
I'm _very_ sure this isn't the case:
a) the machine has 64 GB of RAM.
b) I can even reproduce it after most processes are
Hi Michael,
Michael Biebl wrote:
> I'm downgrading this to non-RC, as I'm not convinced this is actually a
> bug in udev
Fair enough. (Actually I already thought about this, too.) While it
still fulfils the requirements for "critical" (as it crashes
everything except the kernel, i.e. the whole
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
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
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
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)
*
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
45 matches
Mail list logo
