Control: reassign -1 systemd
Hello Michael, Thank you for the quick reply. I'm reassigning it because I think I have some explanations that have made me conclude that it might be a systemd bug. But please feel free to reassign back, in case I'm wrong. On Saturday 04 July 2015 07:54 PM, Michael Biebl wrote: > laptop-mode-tools: /etc/acpi/actions/lm_ac_adapter.sh > laptop-mode-tools: /etc/acpi/actions/lm_battery.sh > laptop-mode-tools: /etc/acpi/actions/lm_lid.sh > laptop-mode-tools: /etc/acpi/events/lm_ac_adapter > laptop-mode-tools: /etc/acpi/events/lm_battery > laptop-mode-tools: /etc/acpi/events/lm_lid > laptop-mode-tools: /etc/apm/event.d/laptop-mode > laptop-mode-tools: /etc/power/event.d/laptop-mode > laptop-mode-tools: /etc/power/scripts.d/laptop-mode > laptop-mode-tools: /lib/systemd/system/laptop-mode.service > laptop-mode-tools: /lib/udev/lmt-udev > laptop-mode-tools: /lib/udev/rules.d/99-laptop-mode.rules > laptop-mode-tools: /usr/lib/pm-utils/sleep.d/01laptop-mode > > I bet the start requests are triggered by one of those scripts. > > If repeated start attempts by those scripts are a problem, then this is > something which needs to be addressed in l-m-t. > The acpid actions will be invoked through the acpid daemon. And that too, when an acpi even is triggered, which usually is when you plug/unplug the power adapter. Where as the log I showed, was while only on battery. And I don't use acpid because systemd/udev are enough for my need. Same goes for udev. l-m-t will only be triggered through udev if a matching event is generated, which as of today, is machinecheck, power_supply and usb. AFAIK power_supply and machinecheck are triggered only when you plug/unplug the power adapter. usb is triggered when a user plugs in a USB device. rrs@learner:~/devel/Laptop-Mode-Tools/laptop-mode-tools (master)$ cat /lib/udev/rules.d/99-laptop-mode.rules ACTION=="change", SUBSYSTEM=="power_supply", RUN+="lmt-udev auto" ACTION=="add|remove", SUBSYSTEM=="machinecheck", RUN+="lmt-udev auto force" ACTION=="add|remove", SUBSYSTEM=="usb", RUN+="lmt-udev force modules=runtime-pm devices=%k" 23:29 ♒♒♒ ☺ >> > >>> >> Another problem is: >>> >> The ExecStart script executes /usr/sbin/laptop_mode, which internally >>> >> backgroups another script, after acquiring a persistent lock. >>> >> For what I've debugged so far, it turns out systemd quietly kills (or >>> >> does not allow invocation of) scripts that are backgrounded >> > >> > Type=oneshot is not supposed to be used for processes which background. > You are using Type=oneshot without RemainAfterExit=yes. > For Type=oneshot, systemd will launch all ExecStart= lines, and proceed > once the spawned process(es) have exited (see the systemd.service). > > Without RemainAfterExit=yes, your service will be inactive (dead) and > systemd will cleanup the complete cgroup.This is the default behaviour > (see man systemd.kill, KillMode defaults to control-group) > Oh!! Sorry. My standard .service file (both upstream and for Debian) is Type=oneshot with RemainAfterExit=yes. https://github.com/rickysarraf/laptop-mode-tools/blob/lmt-upstream/etc/systemd/laptop-mode.service It is just that today, while debugging, I kept playing around thinking I may have missed something. I'm still new on systemd. I have also filed a bug on github so that I can get opinions from other packagers from other distributions, who all are using systemd. https://github.com/rickysarraf/laptop-mode-tools/issues/45 If you go through the bug report on github, I feel the reason all invocations are from systemd. I put a $PPID to check that, and in both invocations you can see the line: Laptop Mode Tools invoked by parent: 1 If it was invoked by udev, I'm an intermediary shell's (/lib/udev/lmt-udev) PID should have been reported, which for sure would not be pid 1. > So issue number one is a l-m-t triggered problem afaics and issue number > two is expected behaviour. > > Thus reassign to l-m-t for issue number one. I've spent the entire Saturday debugging with no substantial root cause. I hope you can point me into the right direction. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System
signature.asc
Description: OpenPGP digital signature
