On Sex, 2016-11-18 at 16:08 +0100, Igor Gnatenko wrote:

On Fri, Nov 18, 2016 at 2:46 PM, Igor Gnatenko ignatenko@redhat.com wrote:

...

Hello @all,

unfortunately I was not able to find updated information how to do that.

%{_udevrulesdir}/foo.rules is fine in %files and BuildRequires: systemd, but there are more questions:

• Should %udev_rules_update be put into %post?
• Should %{?systemd_requires} be presented in spec? probably

something else?

Looks like non of above: (03:31:38 PM) dreisner: ignatenkobrain: no, it isn't (03:32:12 PM) dreisner: assuming it does something silly like 'udevadm control --reload' (03:33:38 PM) ignatenkobrain: dreisner: yes, it does udevadm control --reload ... (03:33:47 PM) dreisner: not needed. (03:34:01 PM) grawity: does udev pick up changes automatically now? (03:37:38 PM) dreisner: it has for years (03:38:08 PM) dreisner: used to do it by inotify. more recently it just looks at timestamps prior to event processing, with some amount of rate limiting.

hum, so use udevadm control --reload is deprecated ?

I review udev rules recently in one of my packages and systemd have 2 services: systemd-udevd.service and systemd-udev-trigger.service

trigger.service  have this command: ExecStart=/usr/bin/udevadm trigger --type=subsystems --action=add ; /usr/bin/udevadm trigger --type=devices --action=add

and caused many problems with last systemd update (if I am correct) , so we shouldn't restart trigger.service service .

Anyway we should add some instructions in guidelines about this matter, even if we don't need add nothing in %post etc

...

-- -Igor Gnatenko

On 18/11/16 15:31, Sérgio Basto wrote:

hum, so use udevadm control --reload is deprecated ?

I review udev rules recently in one of my packages and systemd have 2 services: systemd-udevd.service and systemd-udev-trigger.service

trigger.service have this command: ExecStart=/usr/bin/udevadm trigger --type=subsystems --action=add ; /usr/bin/udevadm trigger --type=devices --action=add

and caused many problems with last systemd update (if I am correct) , so we shouldn't restart trigger.service service .

I think you're confusing two different things...

The first is whether udev loads the new rules - that should happen automatically but could be done manually with the "udevadm control --reload" command.

The second is whether those new/updated rules are applied to existing devices - they will always be applied when reacting to future add/change/remove events but you need to replay events with "udevadm trigger" to apply them to existing devices.

I suspect that the udev people would tell you it's a bad idea to do that though, as you unless you target the trigger very narrowly you are going to make all sorts of things happen. A global "add" trigger for example is basically pretending that all devices have suddenly been plugged in without being removed first.

Tom