[systemd-devel] Race condition between udev rules and hwdb

[Peter Hutterer]

Hi all,

I think there is some race conditions between the udev rules and the hwdb
and I cannot rely that udev rules are applied consistently on a device.  

For reference, after building libinput run
  sudo ./build/libinput-test-suite-runner 
--filter-test=lid_update_hw_on_key_multiple_keyboards
run it repeatedly and at some point it will fail.

The source of the issue is the udev properties for the test device
*sometimes* get overwritten by the hwdb value of a rule with a lower lexical
ordering. In other words: 90-something.hwdb+rules overwrites
99-myrule.rules, that shouldn't happen (or at least not randomly).

For more detail, the relevant parts are:

90-foo.hwdb entry with a dmi match that assigns a property

libinput:name:*Lid Switch*:dmi:*:ct9:*
 LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=reliable

and the matching 90-foo.rules:
KERNELS=="input*", \
  IMPORT{builtin}="hwdb 'libinput:name:$attr{name}:$attr{[dmi/id]modalias}'"

This assigns 'reliable' to the device.

I also have per-device udev rules, 92-foo.rules, in this case: 

ATTRS{name}=="litest Lid Switch Surface3*", \
ENV{ID_INPUT_SWITCH}="1", \
ENV{LIBINPUT_ATTR_LID_SWITCH_RELIABILITY}="write_open"

This overwrites 'reliable' with 'write_open'.

On test-runner start, we install all the udev rules and hwdb files, run hwdb
--update and then start the tests.

In *most* cases, 'write_open' is correctly assigned to the device. In the
failure cases, 'reliable' is assigned. Nothing changes in the udevadm test
output and I've verified that the order appears to change, in the failure
cases the 92-foo.rules applies before the hwdb overwrites it:

ATTRS{name}=="litest Lid Switch Surface3*",
ENV{ID_INPUT_SWITCH}="1",
ENV{BONGO}="litest",
ENV{LIBINPUT_ATTR_LID_SWITCH_RELIABILITY}="write_open"

ATTRS{name}=="litest Lid Switch Surface3*",
ENV{FIRSTVAL}="$env{LIBINPUT_ATTR_LID_SWITCH_RELIABILITY}"

Running with this udev rule shows that FIRSTVAL is write_open but the real
property is 'reliable'. 

This happens anywhere between 1 out of 3 and 1 out of 50, though it seems to
be more common when creating/removing uinput devices like crazy.

What's going on here and where could the issue lie?

Thanks

Cheers,
   Peter
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers

[Michael Chapman]

On Mon, 5 Feb 2018, Johannes Ernst wrote:
It appears systemd-sysusers does not create home directories. On the 
other hand, it picks (largely unpredictable) UIDs from a range.


So I have to run systemd-sysusers, and after that, find the UID of the 
user and chown the home directory? Or is there the equivalent of the 
“useradd -m” flag somewhere that I’m just not seeing?


systemd-sysusers is, as the name suggests, really for _system_ users, and 
often those kinds of users don't have ordinary home directories -- that 
is, ones the user can actually write to.


However, systemd-sysusers.service is ordered before 
systemd-tmpfiles-setup.service at boot, so if you need to create a system 
user's home directory and ensure its ownership is correct, you could use a 
corresponding tmpfiles.d fragment to do so.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-sysusers

[Johannes Ernst]

It appears systemd-sysusers does not create home directories. On the other 
hand, it picks (largely unpredictable) UIDs from a range.

So I have to run systemd-sysusers, and after that, find the UID of the user and 
chown the home directory? Or is there the equivalent of the “useradd -m” flag 
somewhere that I’m just not seeing?

Thanks,



Johannes.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel