]] Ritesh Raj Sarraf Hiya,
> On Sunday 28 October 2012 03:18 PM, Tollef Fog Heen wrote: > >> [Service] > >> > Type=simple > > I suspect you want type=forking here? > > I had tried that too. But it inherits similar problems. [...] > It stopped clean. No locks are help and the status shows correct. Ok, so it seems like start + stop works, but restart then fails? > Now I did a start again. > > rrs@champaran:/var/lock$ sudo systemctl start laptop-mode.service > Job failed. See system journal and 'systemctl status' for details. > > rrs@champaran:/run/lock$ sudo systemctl status laptop-mode.service > [sudo] password for rrs: > laptop-mode.service - Laptop Mode Tools > Loaded: loaded (/lib/systemd/system/laptop-mode.service; enabled) > Active: activating (start) since Sun, 28 Oct 2012 22:01:25 > +0530; 41s ago > Process: 4083 ExecStopPost=/bin/rm -f > /var/run/laptop-mode-tools/enabled (code=exited, status=0/SUCCESS) > Process: 3379 ExecStop=/usr/sbin/laptop_mode init stop > (code=exited, status=0/SUCCESS) > Main PID: 3248 (code=killed, signal=TERM); Control: 4132 > (laptop_mode) > CGroup: name=systemd:/system/laptop-mode.service > ├ 4132 /bin/sh /usr/sbin/laptop_mode init auto > ├ 4150 /bin/sh > /usr/share/laptop-mode-tools/module-helpers/lm-polling-daemon > └ 4152 sleep 150 > > Oct 28 22:01:25 champaran laptop-mode[4329]: Executing: echo 1200000 > > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq > Oct 28 22:01:25 champaran su[4327]: Successful su for rrs by root > Oct 28 22:01:25 champaran su[4327]: + ??? root:rrs > Oct 28 22:01:25 champaran su[4327]: pam_unix(su:session): session opened > for user rrs by (uid=0) > Oct 28 22:01:25 champaran laptop-mode[4471]: Executing comand > Oct 28 22:01:25 champaran laptop-mode[4695]: Executing: echo 2601000 > > /sys/devices/system/cpu/cpu6/cpufreq/scaling_max_freq > > Here, The status shows that it was hung. The systemd status reported was > "activating". This status lasted for 41 seconds. I think you need to figure out why the «laptop_mode init auto» script doesn't exit properly. Try adding a bit of logging logic in there?? > Once it exited as failed, I again checked the status and systemd too > reported it as failed, as below. > > rrs@champaran:/var/lock$ sudo systemctl status laptop-mode.service > laptop-mode.service - Laptop Mode Tools > Loaded: loaded (/lib/systemd/system/laptop-mode.service; enabled) > Active: failed (Result: timeout) since Sun, 28 Oct 2012 > 22:02:55 +0530; 2min 49s ago [...] > Apart from the above logs I have provided of consecutive stop/start of > LMT, how would systmed deal the following case: > > * LMT was started by systemd. Then I switched to BATT. polling script > was invoked and the main script ran and clean exited. Now I switch back > to AC. Will systemd again invoke LMT ? If something calls systemctl restart laptop-mode.service, sure. systemd by itself won't restart it. > * LMT is designed to act on events. The events invoke LMT. The events > come form acpid or udev. Since the invocation could come from either one > (and also manually through the init script) and in multiple event > numbers (udev likes to fire multiple events), we have a lock to ensure > that only 1 event gets processed in a given window. > Will systemd interfere here? Since systemd is also events based, does it > do anything special? I was hoping that systemd also would catch events > and just invoke LMT, in which case, LMT would still be able to handle it > with its locking. But that is not the case. > You can see this here: systemd shouldn't do anything special, no. [...] > If it is not too much to ask, and if you have the time, you may want to > install LMT and check it yourself. Not everything is crisp in my english. > Please let me know if you'd be willing to. I can prepare the new deb for > you, that I am currently holding for release, because of this issue. I don't really have the time to debug laptop-mode for you, I'm afraid, but I'll do my best to answer your questions. As for your English, it seems quite impeccable to me, so don't worry about that. :-) [...] > Can you shed some light what timeout is here being referred to? I can't > find a bug in the LMT script related to timeout yet. I works fine right > now under SysV init. systemd times out services that haven't finised starting up in (by default) 90 seconds. This can be changed with the TimeoutSec setting in the .service file. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
