Re: [systemd-devel] [udev] Limitation of capturing remove events?
On Tue, Sep 1, 2015 at 6:32 AM, Tom Yan 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?
>
AFAIK, the former two come from the uevent itself, but the latter are
always read from sysfs... and during a remove event, the device is not in
sysfs anymore.
(Even more, some sysfs attributes might themselves query data directly from
the device, which wouldn't work well if the device is no longer connected.)
So IMHO you should match on udev's ENV{} instead, and cache the desired
attributes into ENV.
--
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] question about sd_bus_slot_unref()
Hi, all
I wonder why the sd_bus_slot_unref() always returns NULL? I expect that I
can check whether the slot->n_ref ==0 by checking its return value.
That is
_public_ sd_bus_slot* sd_bus_slot_unref(sd_bus_slot *slot) {
if (!slot)
return NULL;
assert(slot->n_ref > 0);
if (slot->n_ref > 1) {
slot->n_ref --;
//return NULL;
retrun slot;
}
bus_slot_disconnect(slot);
free(slot->description);
free(slot);
return NULL;
}
As the libsystem doesn't provide some API for the application to get the n_ref
from the sd_bus_slot, maybe we can provide the same feature this way?
Thanks!
Li Cheng
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 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-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/000
[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
http://lists.fr
Re: [systemd-devel] udev event on usb unpluged
>I do not think you can get a useful event from udev for filesystem unmounting. ok fine. >But you should be able to get events for device removal Could someone provide the simplest .rule to catch such event ?? Christophe - Mail original - De: "Tom Yan" À: "christophe jalady" Cc: "Robert Milasan" , "systemd" Envoyé: Dimanche 30 Août 2015 05:13:08 Objet: Re: [systemd-devel] udev event on usb unpluged First of all I meant "Are you sure that the add events in jc.log actually appears AFTER you plugin anything?". If it appears BEFORE the device is plugged, then the two events are just of the bus/hub. I do not think you can get a useful event from udev for filesystem unmounting. That's simply not what udev is about. But you should be able to get events for device removal (even "devices" created by dummy_hcd/g_mass_storage, btw I think it's better to use `modprobe -r` than `rmmod`, just like `modprobe` vs `insmod`) On 30 August 2015 at 03:43, wrote: >>re 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. > > I'll check that but you are right: it could explain the behavior. > > But then, back to my first question: > Is it possible to get an event from udev (or whatever) alerting that: either > the g_mass_storage is unmounted by the other host _or_ that an usb cable is > unplugged. > > > I'll check for the rest of your answer. (thanks by the way!) > > Christophe > > > > - Mail original - > De: "Tom Yan" > À: "christophe jalady" > Cc: "Robert Milasan" , "systemd" > > Envoyé: Samedi 29 Août 2015 19:54:20 > Objet: 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, 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 2>&1" 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" >> À: "christophe jalady" >> 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) >> 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 2>&1' >> >> Do the necessary removal of the usb cable or whatever, then attach >> the usb cable again, login again and check the log. >> >>> >>>
Re: [systemd-devel] udev event on usb unpluged
>By the way, Milasan asked you to use -u and -p for udevadm monitor. See attached the logs with -u and -p parameters (seem's that it's less than without). Christophe - Mail original - De: "Tom Yan" À: "christophe jalady" Cc: "Robert Milasan" , "systemd" Envoyé: Samedi 29 Août 2015 19:54:20 Objet: 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, 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 2>&1" 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" > À: "christophe jalady" > 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) > 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 2>&1' > > 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 >monitor will print the received events for: UDEV - the event which udev sends out after rule processing UDEV [73.327514] change /devices/platform/leds_pwm/leds/ev3-left1:green:ev3dev (leds) ACTION=change DEVPATH=/devices/platform/leds_pwm/leds/ev3-left1:green:ev3dev ID_PATH=platform-leds_pwm ID_PATH_TAG=platform-leds_pwm SEQNUM=991 SUBSYSTEM=leds TRIGGER=default-on USEC_INITIALIZED=3862 UDEV [73.379486] change /devices/platform/leds_pwm/leds/ev3-right1:green:ev3dev (leds) ACTION=change DEVPATH=/devices/platform/leds_pwm/leds/ev3-right1:green:ev3dev ID_PATH=platform-leds_pwm ID_PATH_TAG=platform-leds_pwm SEQNUM=992 SUBSYSTEM=leds TRIGGER=default-on USEC_INITIALIZED=2431 UDEV [73.418305] change /devices/platform/leds_pwm/leds/ev3-left0:red:ev3dev (leds) ACTION=change DEVPATH=/devices/platform/leds_pwm/leds/ev3-left0:red:ev3dev ID_PATH=platform-leds_pwm ID_PATH_TAG=platform-leds_pwm SEQNUM=993 SUBSYSTEM=leds TRIGGER=none USEC_INITIALIZED=4334 UDEV [73.559291] change /devices/platform/leds_pwm/leds/ev3-right0:red:ev3dev (leds) ACTION=change DEVPATH=/devices/platform/leds_pwm/leds/ev3-right0:red:ev3dev ID_PATH=platform-leds_pwm ID_PATH_TAG=platform-leds_pwm SEQNUM=995 SUBSYSTEM=leds TRIGGER=none USEC_INITIALIZED=9992 UDEV [74.365429] change /devices/platform/leds_pwm/leds/ev3-left0:red:ev3dev (leds) ACTION=change DEVPATH=/devices/pl
Re: [systemd-devel] Access to encrypted partition fails
With an encrypted home partition and a tainted kernel, access to the home partition fails. U folks are upstream to scientific Linux 7. Is there any way to recover / access to an encrypted partition that suffered from a tainted kernel crash? Some logged messages: Failed to activate Input/Output Error Failed to start cryptography setup luks-# etc. Dependency failed for encrypted volume Dependency failed for dev-mapper luks- etc Dependency failed for /home rhel-autorelable-mark service has failed If I can't get access to the partion, it will be time time to bulldoze the system. Any help appreciated. pizza crazy On Mon, Aug 31, 2015 at 2:13 PM, sour kraut wrote: > With an encrypted home partition and a tainted kernel, access to the home > partition fails. U folks are upstream to scientific Linux 7. > > Is there any way to recover / access to an encrypted partition that > suffered from a > tainted kernel crash? > > Some logged messages: > Failed to activate Input/Output Error > Failed to start cryptography setup luks-# etc. > Dependency failed for encrypted volume > Dependency failed for dev-mapper luks- etc > Dependency failed for /home > rhel-autorelable-mark service has failed > > If I can't get access to the partion, > it will be time time to bulldoze the system. > > Any help appreciated. > > Pizza Crazy > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Backport git notes
Lennart Poettering píše v Čt 27. 08. 2015 v 18:02 +0200: > Heya, > > I used to add "Backport: bugfix" style "git notes" to systemd commits > I deemed backport-worthy. These headers have not been added to any > commits since we moved to github (primarily, because the notes > weren't > ported over for quite some time). Nobody complained about this. Which > makes me wonder if anyone actually cares. > > Zbigniew, Michael, Martin, Lukasz, Michal, do you actually care for > these git notes? Did you ever use them? Did you even know about them? > > If nobody cares I can stop doing the work for them, of course, and > less work I always like. > > The git notes usage in our repo is documented here: > > https://wiki.freedesktop.org/www/Software/systemd/Backports/ > > Lennart > We have never did "mass backport", because most of them were irrelevant for our ancient systemd in rhel. It is handy when I am looking for some bugfix in upstream and the first step was to go through such patches. By the way it might be a good topic for the conference to talk about systemd and LTS distributions. Our 208 was quite un-maintainable just after two years. Maybe LTS ubuntus and Debian stable will have similar issues. Lukas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Kdbus - dbus daemon
Hi On Mon, Aug 31, 2015 at 8:02 AM, arnaud gaboury wrote: > Distro : Arch > Systemd : 224 > Kdbus AUR package installed (kdbus module is not in default Arch Kernel) > nspawn container : Fedora 22, systemd 219 > > > I want to give a try to kdbus. If I read correctly the kdbus[0] website: > . > Am I right to understand I will no more need dbus.service and I can > disable it for system and users ? Yes, you can even remove /usr/bin/dbus-daemon. > Will it change something for the container, as it is running a lower > version of systemd ? You can run dbus-daemon in containers and kdbus on the host just fine (or vice versa). However, if you run kdbus in the container, it must use systemd-224 (preferably systemd-225). > Thank you for tips. > > [0]http://www.freedesktop.org/wiki/Software/systemd/kdbus/ Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
