Responding back in rich text, so that the code formatting doesn't annoy the reader.
On Monday 06 July 2015 01:28 PM, Michael Biebl wrote:
> > Something like that is going in the right direction. > You are
backgrounding the subshell here, so there might still be issue > that
the lmt-udev script is killed before you can call systemctl. > So I
suspect there is still a race condition. I guess you could test > that
by simply adding a sleep 10 before systemctl --non-block. > > I would
suggest moving the systemctl code outside of the backgrounded >
subshell, i.e. the ( ) ... code block > > See [1] as an example. >
Thank you. That was a very helpful example.
So now I have:
rrs@learner:~$ cat /lib/udev/lmt-udev
#!/bin/sh -e
# /usr is not guaranteed to be mounted when udev starts
non_systemd_way() {
if [ -e /lib/udev/hotplug.functions ]; then
. /lib/udev/hotplug.functions
wait_for_file /usr/sbin/laptop_mode
exec /usr/sbin/laptop_mode "$@"
else
file=$1
timeout=$2
[ "$timeout" ] || timeout=120
count=$timeout
while [ $count != 0 ]; do
[ -e "/usr/sbin/laptop_mode" ] && exec
/usr/sbin/laptop_mode "$@" && return 0
sleep 1
count=$(($count - 1))
done
mesg "$file did not appear before the timeout!"
exit 1
fi
}
# Under systemd, we don't do synchronous operations, so we can
run in the foreground;
# And we need also need to run in foreground, because forked
children get kill immediately
# under systemd/udev
if [ -d /run/systemd/system ]; then
exec systemctl --no-block reload
laptop-mode
else
# Under sysvinit/upstart, we need to fork as we start
the long-running
# /usr/sbin/laptop_mode
process.
#
# Also, if this happens during boot, we may want to wait
until /usr is available
# This else stanza is going to be used rarely, because
going forward we are
# going to use
systemd.
# But for compatibility reasons, we'll carry
this
#
# That said, we background the execution here, becauser,
otherwise udevd will wait
# for this process which will block
exec > /dev/null 2>dev/null
non_systemd_way "$@" &
fi
exit 0
16:42 ♒♒♒ ☺
And the best part is, now, when my users will ask systemctl for a status
on laptop-mode.service, they'll get all invocations accounted.
rrs@learner:~$ sudo systemctl status laptop-mode.service
● laptop-mode.service - Laptop Mode Tools
Loaded: loaded (/lib/systemd/system/laptop-mode.service;
enabled; vendor preset: enabled)
Active: active (exited) since Mon 2015-07-06 16:29:16 IST;
19min ago
Process: 5579 ExecReload=auto (code=exited, status=0/SUCCESS)
Process: 1124 ExecStart=init auto (code=exited, status=0/SUCCESS)
Main PID: 1124 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/laptop-mode.service
Jul 06 16:29:16 learner laptop-mode[1237]: enabled, not active
Jul 06 16:29:16 learner systemd[1]: Started Laptop Mode Tools.
Jul 06 16:39:08 learner laptop-mode[4322]: Laptop mode
Jul 06 16:39:08 learner laptop-mode[4323]: enabled, not active
[unchanged]
Jul 06 16:39:08 learner systemd[1]: Reloaded Laptop Mode Tools.
Jul 06 16:39:22 learner laptop-mode[4385]: enabled, active
Jul 06 16:39:23 learner systemd[1]: Reloaded Laptop Mode Tools.
Jul 06 16:41:07 learner laptop-mode[4921]: enabled, not active
Jul 06 16:41:07 learner systemd[1]: Reloaded Laptop Mode Tools.
Jul 06 16:44:41 learner systemd[1]: Reloaded Laptop Mode Tools.
16:48 ♒♒♒ ☺
So now, I'm going to add similar check conditions for the pm-utils hook
and the acpid hook.
--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
signature.asc
Description: OpenPGP digital signature
