in a world of race conditions.
>
> On Sun, Jan 10, 2016, 16:25 Tom Yan <tom.t...@gmail.com> wrote:
>>
>> So I am recently experiencing some issue with pulseaudio (which I
>> already filed a bug report:
>> https://bugs.freedesktop.org/show_bug.cgi?id=93651) that
that. If you don't
>> want to wait until it starts, *and* don't want to socket-activate it,
>> the third option is to live in a world of race conditions.
>>
>> On Sun, Jan 10, 2016, 16:25 Tom Yan <tom.t...@gmail.com
>> <mailto:tom.t...@gmail.com>> wrote:
>>
Is it a limitation or bug that I can only capture remove events with
purely SUBSYSTEM or KENREL match, but not with ATTR{*} or even DRIVER?
I unplugged and re-plugged the specific device once before each `cat test`:
[tom@localhost ~]$ cat /etc/udev/rules.d/usb.rules
KERNEL=="1-14",
Also attach a log of `udevadm monitor` for your reference.
On 1 September 2015 at 11:32, Tom Yan <tom.t...@gmail.com> wrote:
> Is it a limitation or bug that I can only capture remove events with
> purely SUBSYSTEM or KENREL match, but not with ATTR{*} or even DRIVER?
>
>
Are you sure that the add events in jc.log actually appears before you
plugin anything? I think usb1 is the host controller/bus and
usb1/1-0:1.0 is the internal hub. If it's that case of course you
won't see any remove event of them by unpluging your device because
the add events doesn't belong to
files and then umount/unplugged the
cable.
When the cable is unplugged, I want to trigger an action on my device
(processing the files copied).
Christophe
- Mail original -
De: Tom Yan tom.t...@gmail.com
À: christophe jalady christophe.jal...@free.fr
Cc: systemd systemd-devel
Maybe there's indeed some problem with your kernel or device. I tried
the following rule on my machine:
/etc/udev/rules.d/usb.rules:SUBSYSTEM==usb, RUN+=/usr/bin/bash -c
'echo $ACTION $DEVPATH /home/tom/test
And here's the test log after I reboot and plug/unplug a usb thumb
drive (2-4):
add
Also it seems to be g_mass_storage is just the module for setting up
dummy or emulating an mass storage device. Why would you want it to
depend on a usb cable/device?
On 26 August 2015 at 11:21, Tom Yan tom.t...@gmail.com wrote:
I am not sure about what you mean here. Do you mean that you can't
I am not sure about what you mean here. Do you mean that you can't see
any remove event with `udevadm monitor` when you unplug the cable?
Also do you really mean a usb cable without any device connected to
it on the other end?
By the way the rule you set up is so broad that the script will
Ah that explains everything. I was just confused about
RUN{builtin}+=uaccess but now I get it. Thanks a lot!
On 20 August 2015 at 18:05, Mantas Mikulėnas graw...@gmail.com wrote:
Well, as in the paste earlier, 73-seat-late.rules is the place where udev
actually looks at the uaccess tag and
, Aug 19, 2015 at 3:18 PM, Robert Milasan rmila...@suse.cz wrote:
On Wed, 19 Aug 2015 17:45:28 +0800
Tom Yan tom.t...@gmail.com wrote:
Hi all!
So I added the following rules:
[tom@localhost ~]$ grep . /etc/udev/rules.d/*
/etc/udev/rules.d/uas.rules:DRIVERS==uas, TAG+=uaccess
/etc/udev/rules.d
Hi all!
So I added the following rules:
[tom@localhost ~]$ grep . /etc/udev/rules.d/*
/etc/udev/rules.d/uas.rules:DRIVERS==uas, TAG+=uaccess
/etc/udev/rules.d/usb-storage.rules:DRIVERS==usb-storage, TAG+=uaccess
The rules basically works, but it doesn't support hotplug, that is,
I have to
Under certain conditions, I discovered that commands like `udevadm
control --exit` or `systemctl stop systemd-udevd` (with the sockets
stopped beforehand) will kill udevd before it finish its jobs which
triggered by `udevadm trigger` (I presume applying a written udev rule
is one of them).
Is
13 matches
Mail list logo
