Re: [systemd-devel] user unit blocking login shell from popping out because wanted by default target?
That's exactly what I meant. There should be a target for units that "need to be waited" and "no need to be waited" respectively. One can argue which one should a sound service fall into with whatever point, but that's out of the scope of the issue I am talking about here. I just thought systemd has implemented this at its very beginning, seems like I was wrong. At I least I got my answer though. Thanks, grawity <3 On 11 January 2016 at 01:15, Mantas Mikulėnas <graw...@gmail.com> wrote: > I remember this discussed before, I think one suggestion was to split into > two targets, and only hold the login until the first target. Nobody > implemented it though. > > But yes, pulseaudio.socket would be a requirement of 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> 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 it takes a >> long time to start. >> >> The thing is, I am thinking whether it exposed a problem of systemd as >> well. For example: >> >> Jan 10 21:31:33 localhost systemd[257]: Starting Sound Service... >> Jan 10 21:31:33 localhost systemd[257]: Started D-Bus User Message Bus. >> Jan 10 21:31:39 localhost systemd[257]: Started Sound Service. >> Jan 10 21:31:39 localhost systemd[257]: Reached target Default. >> Jan 10 21:31:39 localhost systemd[257]: Startup finished in 5.830s. >> >> As you can see, because of pulseaudio, it takes about 6 seconds to >> reach the default target. >> >> The reason I realise that pulseaudio is having this issue, is because >> I can actually "experience" the 6 seconds after I entered my password >> in the tty, if I have pulseaudio.service enabled. The login shell only >> pops up after the default target has been reached. >> >> But isn't the very first goal of systemd avoiding delay like this? Is >> it considered normal that the login shell only pops up after it >> reached the default target? In that case, isn't it bad to have >> pulseaudio.service wanted by the default target (instead of some >> target that will not block the login shell)? >> >> Ironically even if I put `pulseaudio &` in ~/.bash_profile to start >> it, I wouldn't "experience" such delay. >> >> Please don't tell me that pulseaudio.socket is the solution, coz it's >> irrelevant to the issue I am talking about. The whole point of >> enabling the service instead of just the socket is to avoid >> "experiencing" the startup of pulse. >> ___ >> systemd-devel mailing list >> systemd-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] user unit blocking login shell from popping out because wanted by default target?
Ugh I am not talking about system units, but user units... P.S. Although not really relevant here, but I am using the (user) service file provided by upstream pulseaudio On 11 January 2016 at 01:30, Reindl Harald <h.rei...@thelounge.net> wrote: > > > Am 10.01.2016 um 18:15 schrieb Mantas Mikulėnas: >> >> I remember this discussed before, I think one suggestion was to split >> into two targets, and only hold the login until the first target. Nobody >> implemented it though. >> >> But yes, pulseaudio.socket would be a requirement of 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: >> >> 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 it takes a >> long time to start. >> >> The thing is, I am thinking whether it exposed a problem of systemd as >> well. For example: >> >> Jan 10 21:31:33 localhost systemd[257]: Starting Sound Service... >> Jan 10 21:31:33 localhost systemd[257]: Started D-Bus User Message >> Bus. >> Jan 10 21:31:39 localhost systemd[257]: Started Sound Service. >> Jan 10 21:31:39 localhost systemd[257]: Reached target Default. >> Jan 10 21:31:39 localhost systemd[257]: Startup finished in 5.830s. >> >> As you can see, because of pulseaudio, it takes about 6 seconds to >> reach the default target > > > no idea how you configured you pulseaudio.service > > but i can assure you that i have systems with pulseaudio as systemwide > daemons where the whol eboot inlcuding VMware, httpd, dbmail and two > mysql-instances takes around 18 seconds > > in fact with "type=simple" it can't delay boot at all > > [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/pulsed.service > [Unit] > Description=Pulseaudio Daemon > After=rtkit-daemon.service systemd-udevd.service dbus.service sddm.service > > [Service] > Type=simple > ExecStart=-/usr/bin/pulseaudio --daemonize=false --system=true > --realtime=true --log-level=0 --log-target=stderr > --disallow-module-loading=true --disallow-exit=true --exit-idle-time=0 > --disable-shm=true --no-cpu-limit=false --use-pid-file=false > --resample-method=src-sinc-best-quality > > Restart=always > RestartSec=30 > TimeoutSec=15 > Nice=-10 > > PrivateTmp=yes > PrivateNetwork=yes > > CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_WRITE CAP_SYS_ADMIN > CAP_SYS_BOOT CAP_SYS_MODULE CAP_SYS_PTRACE > > ReadOnlyDirectories=/etc > ReadOnlyDirectories=/usr > ReadOnlyDirectories=/var > ReadWriteDirectories=/var/lib/pulse > > InaccessibleDirectories=-/boot > InaccessibleDirectories=-/home > InaccessibleDirectories=-/media > InaccessibleDirectories=-/root > > > [Install] > WantedBy=multi-user.target > > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [udev] Limitation of capturing remove events?
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", RUN+="/usr/bin/bash -c 'echo $DEVPATH $ACTION >>
/home/tom/test'"
[tom@localhost ~]$ sudo systemctl restart systemd-udevd systemd-udev-trigger
[tom@localhost ~]$ cat test
/devices/pci:00/:00:14.0/usb1/1-14 add
/devices/pci:00/:00:14.0/usb1/1-14 remove
/devices/pci:00/:00:14.0/usb1/1-14 add
[tom@localhost ~]$ sudo rm test
[tom@localhost ~]$ cat /etc/udev/rules.d/usb.rules
SUBSYSTEM=="usb", ATTR{busnum}=="1", ATTR{devpath}=="14",
RUN+="/usr/bin/bash -c 'echo $DEVPATH $ACTION >> /home/tom/test'"
[tom@localhost ~]$ sudo systemctl restart systemd-udevd systemd-udev-trigger
[tom@localhost ~]$ cat test
/devices/pci:00/:00:14.0/usb1/1-14 add
/devices/pci:00/:00:14.0/usb1/1-14 add
[tom@localhost ~]$ sudo rm test
[tom@localhost ~]$ cat /etc/udev/rules.d/usb.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="046d", ATTR{idProduct}=="c52e",
RUN+="/usr/bin/bash -c 'echo $DEVPATH $ACTION >> /home/tom/test'"
[tom@localhost ~]$ sudo systemctl restart systemd-udevd systemd-udev-trigger
[tom@localhost ~]$ cat test
/devices/pci:00/:00:14.0/usb1/1-14 add
/devices/pci:00/:00:14.0/usb1/1-14 add
[tom@localhost ~]$ sudo rm test
[tom@localhost ~]$ cat /etc/udev/rules.d/usb.rules
KERNEL=="2-6", RUN+="/usr/bin/bash -c 'echo $DEVPATH $ACTION >> /home/tom/test'"
[tom@localhost ~]$ sudo systemctl restart systemd-udevd systemd-udev-trigger
[tom@localhost ~]$ cat test
/devices/pci:00/:00:14.0/usb2/2-6 add
/devices/pci:00/:00:14.0/usb2/2-6 remove
/devices/pci:00/:00:14.0/usb2/2-6 add
[tom@localhost ~]$ sudo rm test
[tom@localhost ~]$ cat /etc/udev/rules.d/usb.rules
ATTR{serial}=="AA011214140810091125", RUN+="/usr/bin/bash -c 'echo
$DEVPATH $ACTION >> /home/tom/test'"
[tom@localhost ~]$ sudo systemctl restart systemd-udevd systemd-udev-trigger
[tom@localhost ~]$ cat test
/devices/pci:00/:00:14.0/usb2/2-6 add
/devices/pci:00/:00:14.0/usb2/2-6 add
[tom@localhost ~]$ sudo rm test
[tom@localhost ~]$ cat /etc/udev/rules.d/usb.rules
SUBSYSTEM=="usb", RUN+="/usr/bin/bash -c 'echo $DEVPATH $ACTION >>
/home/tom/test'"
[tom@localhost ~]$ sudo systemctl restart systemd-udevd systemd-udev-trigger
[tom@localhost ~]$ cat test
/devices/pci:00/:00:14.0/usb1 add
/devices/pci:00/:00:14.0/usb2 add
/devices/pci:00/:00:14.0/usb2/2-6 add
/devices/pci:00/:00:14.0/usb2/2-1 add
/devices/pci:00/:00:14.0/usb2/2-0:1.0 add
/devices/pci:00/:00:14.0/usb2/2-1/2-1:1.0 add
/devices/pci:00/:00:14.0/usb2/2-6/2-6:1.0 add
/devices/pci:00/:00:14.0/usb1/1-0:1.0 add
/devices/pci:00/:00:1a.0/usb3 add
/devices/pci:00/:00:14.0/usb1/1-14 add
/devices/pci:00/:00:1d.0/usb4 add
/devices/pci:00/:00:1d.0/usb4/4-0:1.0 add
/devices/pci:00/:00:1a.0/usb3/3-0:1.0 add
/devices/pci:00/:00:1d.0/usb4/4-1 add
/devices/pci:00/:00:1d.0/usb4/4-1/4-1:1.0 add
/devices/pci:00/:00:1a.0/usb3/3-1 add
/devices/pci:00/:00:14.0/usb1/1-14/1-14:1.1 add
/devices/pci:00/:00:14.0/usb1/1-14/1-14:1.0 add
/devices/pci:00/:00:1a.0/usb3/3-1/3-1:1.0 add
/devices/pci:00/:00:14.0/usb1/1-14/1-14:1.0 remove
/devices/pci:00/:00:14.0/usb1/1-14/1-14:1.1 remove
/devices/pci:00/:00:14.0/usb1/1-14 remove
/devices/pci:00/:00:14.0/usb1/1-14 add
/devices/pci:00/:00:14.0/usb1/1-14/1-14:1.0 add
/devices/pci:00/:00:14.0/usb1/1-14/1-14:1.1 add
/devices/pci:00/:00:14.0/usb2/2-6/2-6:1.0 remove
/devices/pci:00/:00:14.0/usb2/2-6 remove
/devices/pci:00/:00:14.0/usb2/2-6 add
/devices/pci:00/:00:14.0/usb2/2-6/2-6:1.0 add
[tom@localhost ~]$ sudo rm test
[tom@localhost ~]$ cat /etc/udev/rules.d/usb.rules
DRIVER=="usb", RUN+="/usr/bin/bash -c 'echo $DEVPATH $ACTION >> /home/tom/test'"
[tom@localhost ~]$ sudo systemctl restart systemd-udevd systemd-udev-trigger
[tom@localhost ~]$ cat test
/devices/pci:00/:00:14.0/usb1 add
/devices/pci:00/:00:14.0/usb2 add
/devices/pci:00/:00:14.0/usb2/2-6 add
/devices/pci:00/:00:1a.0/usb3 add
/devices/pci:00/:00:14.0/usb2/2-1 add
/devices/pci:00/:00:14.0/usb1/1-14 add
/devices/pci:00/:00:1a.0/usb3/3-1 add
/devices/pci:00/:00:1d.0/usb4 add
/devices/pci:00/:00:1d.0/usb4/4-1 add
/devices/pci:00/:00:14.0/usb1/1-14 add
/devices/pci:00/:00:14.0/usb2/2-6 add
Attached are the outputs of `udevadm info -a` on the two devices used
in the trials.
info_1_14
Description: Binary data
info_2_6
Description: Binary data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
Re: [systemd-devel] [udev] Limitation of capturing remove events?
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?
>
> 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", RUN+="/usr/bin/bash -c 'echo $DEVPATH $ACTION >>
> /home/tom/test'"
> [tom@localhost ~]$ sudo systemctl restart systemd-udevd systemd-udev-trigger
> [tom@localhost ~]$ cat test
> /devices/pci:00/:00:14.0/usb1/1-14 add
> /devices/pci:00/:00:14.0/usb1/1-14 remove
> /devices/pci:00/:00:14.0/usb1/1-14 add
> [tom@localhost ~]$ sudo rm test
>
> [tom@localhost ~]$ cat /etc/udev/rules.d/usb.rules
> SUBSYSTEM=="usb", ATTR{busnum}=="1", ATTR{devpath}=="14",
> RUN+="/usr/bin/bash -c 'echo $DEVPATH $ACTION >> /home/tom/test'"
> [tom@localhost ~]$ sudo systemctl restart systemd-udevd systemd-udev-trigger
> [tom@localhost ~]$ cat test
> /devices/pci:00/:00:14.0/usb1/1-14 add
> /devices/pci:00/:00:14.0/usb1/1-14 add
> [tom@localhost ~]$ sudo rm test
>
> [tom@localhost ~]$ cat /etc/udev/rules.d/usb.rules
> SUBSYSTEM=="usb", ATTR{idVendor}=="046d", ATTR{idProduct}=="c52e",
> RUN+="/usr/bin/bash -c 'echo $DEVPATH $ACTION >> /home/tom/test'"
> [tom@localhost ~]$ sudo systemctl restart systemd-udevd systemd-udev-trigger
> [tom@localhost ~]$ cat test
> /devices/pci:00/:00:14.0/usb1/1-14 add
> /devices/pci:00/:00:14.0/usb1/1-14 add
> [tom@localhost ~]$ sudo rm test
>
> [tom@localhost ~]$ cat /etc/udev/rules.d/usb.rules
> KERNEL=="2-6", RUN+="/usr/bin/bash -c 'echo $DEVPATH $ACTION >>
> /home/tom/test'"
> [tom@localhost ~]$ sudo systemctl restart systemd-udevd systemd-udev-trigger
> [tom@localhost ~]$ cat test
> /devices/pci:00/:00:14.0/usb2/2-6 add
> /devices/pci:00/:00:14.0/usb2/2-6 remove
> /devices/pci:00/:00:14.0/usb2/2-6 add
> [tom@localhost ~]$ sudo rm test
>
> [tom@localhost ~]$ cat /etc/udev/rules.d/usb.rules
> ATTR{serial}=="AA011214140810091125", RUN+="/usr/bin/bash -c 'echo
> $DEVPATH $ACTION >> /home/tom/test'"
> [tom@localhost ~]$ sudo systemctl restart systemd-udevd systemd-udev-trigger
> [tom@localhost ~]$ cat test
> /devices/pci:00/:00:14.0/usb2/2-6 add
> /devices/pci:00/:00:14.0/usb2/2-6 add
> [tom@localhost ~]$ sudo rm test
>
> [tom@localhost ~]$ cat /etc/udev/rules.d/usb.rules
> SUBSYSTEM=="usb", RUN+="/usr/bin/bash -c 'echo $DEVPATH $ACTION >>
> /home/tom/test'"
> [tom@localhost ~]$ sudo systemctl restart systemd-udevd systemd-udev-trigger
> [tom@localhost ~]$ cat test
> /devices/pci:00/:00:14.0/usb1 add
> /devices/pci:00/:00:14.0/usb2 add
> /devices/pci:00/:00:14.0/usb2/2-6 add
> /devices/pci:00/:00:14.0/usb2/2-1 add
> /devices/pci:00/:00:14.0/usb2/2-0:1.0 add
> /devices/pci:00/:00:14.0/usb2/2-1/2-1:1.0 add
> /devices/pci:00/:00:14.0/usb2/2-6/2-6:1.0 add
> /devices/pci:00/:00:14.0/usb1/1-0:1.0 add
> /devices/pci:00/:00:1a.0/usb3 add
> /devices/pci:00/:00:14.0/usb1/1-14 add
> /devices/pci:00/:00:1d.0/usb4 add
> /devices/pci:00/:00:1d.0/usb4/4-0:1.0 add
> /devices/pci:00/:00:1a.0/usb3/3-0:1.0 add
> /devices/pci:00/:00:1d.0/usb4/4-1 add
> /devices/pci:00/:00:1d.0/usb4/4-1/4-1:1.0 add
> /devices/pci:00/:00:1a.0/usb3/3-1 add
> /devices/pci:00/:00:14.0/usb1/1-14/1-14:1.1 add
> /devices/pci:00/:00:14.0/usb1/1-14/1-14:1.0 add
> /devices/pci:00/:00:1a.0/usb3/3-1/3-1:1.0 add
> /devices/pci:00/:00:14.0/usb1/1-14/1-14:1.0 remove
> /devices/pci:00/:00:14.0/usb1/1-14/1-14:1.1 remove
> /devices/pci:00/:00:14.0/usb1/1-14 remove
> /devices/pci:00/:00:14.0/usb1/1-14 add
> /devices/pci:00/:00:14.0/usb1/1-14/1-14:1.0 add
> /devices/pci:00/:00:14.0/usb1/1-14/1-14:1.1 add
> /devices/pci:00/:00:14.0/usb2/2-6/2-6:1.0 remove
> /devices/pci:00/:00:14.0/usb2/2-6 remove
> /devices/pci:00/:00:14.0/usb2/2-6 add
> /devices/pci:00/:00:14.0/usb2/2-6/2-6:1.0 add
> [tom@localhost ~]$ sudo rm test
>
> [tom@localhost ~]$ cat /etc/udev/rules.d/usb.rules
> DRIVER=="usb", RUN+="/usr/bin/bash -c 'echo $DEVPATH $ACTION >>
> /home/tom/test'"
> [tom@localhost ~]$ sudo systemctl restart systemd-udevd systemd-udev
Re: [systemd-devel] udev event on usb unpluged
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 the device as well. In that case, perhaps for some reason your device isn't under the usb subsystem, so the rule is a mismatch for it. As for the `udevadm monitor` log, I don't know how/when exactly your init.d script is ran, but actually you don't have to do it that way. You can just boot up, start capturing udevadm monitor output, then restart systemd-udev-trigger.serivce (or `/usr/bin/udevadm trigger --type=subsystems --action=add ; /usr/bin/udevadm trigger --type=devices --action=add` if you aren't running systemd, that's what the service run), then stop capturing, and you'll basically see what happened when it boot. By the way, Milasan asked you to use -u and -p for udevadm monitor. On 29 August 2015 at 23:30, christophe.jal...@free.fr wrote: sorry for the delay. Attached are the logs. The log show the hole process meaning: Boot Plug of the usb cable: the device is shown as a mass-storage on the other device. Other device umount. I unplug the cable. Shutdown of the device. 'jc.log' is the log from my script. You will see 2 add event, but no remove event. 'udev.log' if the log from udevadm monitor /var/log/udev.log 21 since boot time (I launch it from an init.d script at startup). 1) Why I see event in my jc.log but not in udev.log ?? 2) Why is there no usb event in udev.log (nor add/change or remove ...) ? For completeness, I attach also my .rule and .sh scripts. Thanks for your help. Christophe - Mail original - De: Robert Milasan rmila...@suse.com À: christophe jalady christophe.jal...@free.fr Cc: systemd-devel@lists.freedesktop.org Envoyé: Mercredi 26 Août 2015 14:35:24 Objet: Re: [systemd-devel] udev event on usb unpluged On Wed, 26 Aug 2015 15:32:13 +0200 (CEST) christophe.jal...@free.fr wrote: They are not referring to your device, but the machine on which you are running the rule. In a terminal/console you run: udevadm monitor The do the removal itself and see what 'udevadm monitor' says. this is the problem: the machine which are running the rule is a specific robotic device with one usb port and no screen (and no network device). Either I connect through ssh using the usb cable (eth over usb) or I use the usb cable to test my plug/unplug process. I cannot have a console _and_ test the unplugging at the same time. Then login into that machine and run screen, in which you run: 'udevadm monitor -u -p /tmp/udev.log 21' Do the necessary removal of the usb cable or whatever, then attach the usb cable again, login again and check the log. Christophe -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmila...@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev event on usb unpluged
Can you paste run `udevadm monitor`, plug in your cable/device, wait for a second, unplug it, and paste the output? Or can you show how you confirmed your script receive the add event, or how the script catch the event? On 26 August 2015 at 15:35, christophe.jal...@free.fr wrote: 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? yes, my script never receive the remove event (_but_ receive the add event). Also do you really mean a usb cable without any device connected to it on the other end? No, the cable is connected to another device. So I want the remove event when the cable is unplugged from one of the device (my device or the other one). Unless you have a very specific to match with, I wonder if it's a good idea to unload the module by a remove event, ...what if there are two cables/devices using the module? Well, my setup is really specific (small robotic device), so it safe to consider only one cable connected. 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? This is the bigger picture: My device is a small robotic device. To send a file on it, I that users just copy files like they do with mass-storage usb-key. So: On usb-plugged: I load the module k_mass_storage: the other device see a new mass-storage device appearing, copy 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@lists.freedesktop.org Envoyé: Mercredi 26 Août 2015 04:37:40 Objet: Re: [systemd-devel] udev event on usb unpluged 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 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 basically be run on every boot or udevadm trigger. Unless you have a very specific to match with, I wonder if it's a good idea to unload the module by a remove event, because, for example, what if there are two cables/devices using the module? On 26 August 2015 at 04:17, christophe.jal...@free.fr wrote: Hi, I would like to receive an event (actually run a script) when I plug/unplugged an usb cable. I tried to use udev with this simple rule: SUBSYSTEM==usb,RUN+=/var/local/usb-changed.sh I do receive the add event when I plug the usb cable: just perfect ! But I never receive the remove event. Any idea why ? More information: I use linux kernel v3.16. When the cable is plugged, I load the kernel module g_mass_storage, this work great. My need is to unload the module when the usb cable is unplugged (note it would be even better if I receive an event when the mass-storage is unmounted by the other host, but I do not have any idea where to look for.) Thanks by advance for any hint. Christophe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev event on usb unpluged
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 /devices/pci:00/:00:1a.0/usb3 add /devices/pci:00/:00:14.0/usb2 add /devices/pci:00/:00:1d.0/usb4 add /devices/pci:00/:00:14.0/usb1 add /devices/pci:00/:00:1d.0/usb4/4-0:1.0 add /devices/pci:00/:00:1a.0/usb3/3-0:1.0 add /devices/pci:00/:00:14.0/usb2/2-0:1.0 add /devices/pci:00/:00:14.0/usb1/1-0:1.0 add /devices/pci:00/:00:14.0/usb2/2-1 add /devices/pci:00/:00:14.0/usb2/2-1/2-1:1.0 add /devices/pci:00/:00:14.0/usb2/2-2 add /devices/pci:00/:00:14.0/usb2/2-2/2-2:1.0 add /devices/pci:00/:00:1a.0/usb3/3-1 add /devices/pci:00/:00:1a.0/usb3/3-1/3-1:1.0 add /devices/pci:00/:00:1d.0/usb4/4-1 add /devices/pci:00/:00:1d.0/usb4/4-1/4-1:1.0 add /devices/pci:00/:00:14.0/usb1/1-13 add /devices/pci:00/:00:14.0/usb1/1-13/1-13:1.0 add /devices/pci:00/:00:14.0/usb1/1-13/1-13:1.1 add /devices/pci:00/:00:14.0/usb1/1-13/1-13:1.2 add /devices/pci:00/:00:14.0/usb1/1-14 add /devices/pci:00/:00:14.0/usb1/1-14/1-14:1.0 add /devices/pci:00/:00:14.0/usb1/1-14/1-14:1.1 add /devices/pci:00/:00:14.0/usb2/2-4 add /devices/pci:00/:00:14.0/usb2/2-4/2-4:1.0 remove /devices/pci:00/:00:14.0/usb2/2-4/2-4:1.0 remove /devices/pci:00/:00:14.0/usb2/2-4 Perhaps you can check the devpath and see if it's actually gone with `ls` after you unplug the cable/device? On 26 August 2015 at 21:35, Robert Milasan rmila...@suse.com wrote: On Wed, 26 Aug 2015 15:32:13 +0200 (CEST) christophe.jal...@free.fr wrote: They are not referring to your device, but the machine on which you are running the rule. In a terminal/console you run: udevadm monitor The do the removal itself and see what 'udevadm monitor' says. this is the problem: the machine which are running the rule is a specific robotic device with one usb port and no screen (and no network device). Either I connect through ssh using the usb cable (eth over usb) or I use the usb cable to test my plug/unplug process. I cannot have a console _and_ test the unplugging at the same time. Then login into that machine and run screen, in which you run: 'udevadm monitor -u -p /tmp/udev.log 21' Do the necessary removal of the usb cable or whatever, then attach the usb cable again, login again and check the log. Christophe -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmila...@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev event on usb unpluged
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 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 basically be run on every boot or udevadm trigger. Unless you have a very specific to match with, I wonder if it's a good idea to unload the module by a remove event, because, for example, what if there are two cables/devices using the module? On 26 August 2015 at 04:17, christophe.jal...@free.fr wrote: Hi, I would like to receive an event (actually run a script) when I plug/unplugged an usb cable. I tried to use udev with this simple rule: SUBSYSTEM==usb,RUN+=/var/local/usb-changed.sh I do receive the add event when I plug the usb cable: just perfect ! But I never receive the remove event. Any idea why ? More information: I use linux kernel v3.16. When the cable is plugged, I load the kernel module g_mass_storage, this work great. My need is to unload the module when the usb cable is unplugged (note it would be even better if I receive an event when the mass-storage is unmounted by the other host, but I do not have any idea where to look for.) Thanks by advance for any hint. Christophe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev event on usb unpluged
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 basically be run on every boot or udevadm trigger. Unless you have a very specific to match with, I wonder if it's a good idea to unload the module by a remove event, because, for example, what if there are two cables/devices using the module? On 26 August 2015 at 04:17, christophe.jal...@free.fr wrote: Hi, I would like to receive an event (actually run a script) when I plug/unplugged an usb cable. I tried to use udev with this simple rule: SUBSYSTEM==usb,RUN+=/var/local/usb-changed.sh I do receive the add event when I plug the usb cable: just perfect ! But I never receive the remove event. Any idea why ? More information: I use linux kernel v3.16. When the cable is plugged, I load the kernel module g_mass_storage, this work great. My need is to unload the module when the usb cable is unplugged (note it would be even better if I receive an event when the mass-storage is unmounted by the other host, but I do not have any idea where to look for.) Thanks by advance for any hint. Christophe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev uaccess tag does not support hotplug for some devices
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 applies initial ACLs on device
connect. So all devices must be properly tagged before they reach that rule.
(Logind /also/ looks at the uaccess tag and applies ACLs independently of
udev rules, but it only does so when switching sessions; it doesn't do
anything when a new device is connected.)
--
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev uaccess tag does not support hotplug for some devices
Woo it's a win of almighty grawity again! \o/
My rules works perfectly fine with the 70- prefix just as the shipped
70-uaccess.rules. Should have thought about it. Any pointer for
details about the consumed here btw?
On 19 August 2015 at 20:43, Mantas Mikulėnas graw...@gmail.com wrote:
On Wed, 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/usb-storage.rules:DRIVERS==usb-storage,
TAG+=uaccess
Can you try:
ACTION==add|change, SUBSYSTEMS==usb,
ENV{ID_USB_DRIVER}==usb-storage, TAG+=uaccess
in usb-storage.rules ?
You might wanna rename the rule to something like 90-usb-storage.rules,
but thats besides the point.
Hmm, in fact, the uaccess tag is consumed by:
73-seat-late.rules:15:TAG==uaccess, ENV{MAJOR}!=, RUN{builtin}+=uaccess
So the ordering might be very relevant.
--
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] udev uaccess tag does not support hotplug for some devices
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 re-login for newly plugged devices to get the ACLs, and I have to do that as well if I replugged the device after I logged in. However, it doesn't seem to be a universal limitation, because it does support hotplug for my SATA optical drive. I enabled hotplug of that SATA port in BIOS, unplugged the SATA cable, made sure cdrom (symlink) and sr0 are no longer in /dev, then plugged it in again, the ACLs remains. I also tried to boot without the optical drive connected, and plugged in after login, it also works fine. So could it be a bug of udev or logind, or something wrong with certain kernel drivers? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] About the exit of systemd-udevd
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 this acceptable/expected? If so, is there any way to guarantee the
jobs is done before it gets killed?
Attached is a script for testing. I think any arbitrary udev rule
could be used for testing. For example I used:
ATTR{devpath}==13, ATTR{power/wakeup}==enabled/disabled
trigger.sh
Description: Bourne shell script
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
