Login hangs after adding systemd rule

Hello all,

I have a strange problem with Leap 15 & KDE desktop.
Everything works fine.
I created a new systemgroup “usbtmc” and I added myself to this group and rebooted.
Everything works fine.
I created a new file /lib/udev/rules.d/30-usbtmc.rules that contains the following:

####################################################################################
# USBTMC instruments

# Rigol Technologies  DS1000Z series
SUBSYSTEMS=="usb", ACTION=="add", ATTRS{idVendor}=="1ab1", ATTRS{idProduct}=="04ce", GROUP="usbtmc", MODE="0660"

# Devices
KERNEL=="usbtmc/*",       MODE="0660", GROUP="usbtmc"
KERNEL=="usbtmc[0-9]*",   MODE="0660", GROUP="usbtmc"
####################################################################################

I rebooted.
Now the system hangs at the point where you can still see the console but there’s already the mouse cursor.
No graphical login yet.

I start a new terminal by using ctrl-alt-f1, login as root and remove the apparently offending file.
I enter “init 6”.
The system hangs because systemd says a stopjob is running for usermanager which takes ages (2 minutes).
I switch-off the power.
I switch it on again.
Everything works fine.

I have two questions:

  1. why is the above procedure working fine on Opensuse Leap 42.3?

  2. why is the new rule causing problems on Leap 15?

Thanks,

Teuniz

First,
Tnat’s a udev rule, not a systemd rule (It’s on the roadmap, somewhere a long time from now systemd wants to replace udev as well).

Sounds like there could be timing problem, the boot parallelism is probably different between 42.3 and 15.
At least you have a working example, you should probably start by mapping out what ihappens just prior to your system freezing in 15 and extract specific errors and not rely just on your observation… Then you can compare with what happens on 42.3.

You’ll want to use journalctl for at least the following

  • Extract prior bootlogs
  • Filter for specific level errors
  • Filter for errors that are specific to udev

I’d recommend the following that describes how to do the above and more

https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs

TSU

Thanks tsu2,

You were right.

I found the cause. I screwed up. When copy and pasting the content of the new udev rule,
somehow a newline character has been inserted.

So, instead of:

SUBSYSTEMS=="usb", ACTION=="add", ATTRS{idVendor}=="1ab1", ATTRS{idProduct}=="04ce", GROUP="usbtmc", MODE="0660"

there was written:

SUBSYSTEMS=="usb", ACTION=="add", ATTRS{idVendor}=="1ab1", ATTRS{idProduct}=="04ce", GROUP="usbtmc",
MODE="0660"

My fault. Apparently this was enough to let the system hang.

Thanks for the interesting info about journalctl.

Teuniz

That’s not what you wrote in your original post so there was no way anyone could guess what happened.

Apparently this was enough to let the system hang.

Second line is interpreted as independent rule which gets applied to every event. So all devices get mode 0660 which may be enough to screw up access.

True. That’s why I wrote that I screwed up and it was my fault.