< ^ txt
Sat Nov 28 09:23:16 EST 2015
Went to bed around midnight and slept until nine. Woke up once around four or five, but otherwise slept well. I feel rested.
Partly sunny with a high of forty-one today.
Goals:
- Go for a walk
Nope.
- Try bspwm (started yesterday)
Done.
Made a few notes. http://paulgorman.org/technical/bspwm.txt
Meh.
Installed it and played with the config a little.
It's fine. But not clearly better than herbstluftwm.
I do like the config by feeding commands to bspc.
I may just go back to fvwm. At least I know it will be maintained for a long time, and it's highly configurable.
I ended up playing with OpenBSD's cwm. It's not bad, although pretty minimalist.
openbsd-cwm(1)
cwmrc(5)
http://blather.michaelwlucas.com/archives/873
The only annoyance with it is that there doesn't seem to be any way to float windows (which I really only want for xclock anyhow).
My quick .cwmrc: http://paulgorman.org/technical/dotfiles/cwmrc.txt
I'm surprised by how much I like cwm. I really like it.
- Clean apartment
Done. Vacuumed, watered plant, and generally tidied up.
- Take one more stab at fixing this issue where fancontrol under systemd doesn't respect my settings after waking from sleep
Done. Fixed.
--- bava 5002 ~ % systemctl list-unit-files | grep fan
fancontrol.service enabled
--- bava 5003 ~ % locate fancontrol.service
/etc/systemd/system/multi-user.target.wants/fancontrol.service
/lib/systemd/system/fancontrol.service
/var/lib/systemd/deb-systemd-helper-enabled/fancontrol.service.dsh-also
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/fancontrol.service
--- bava 5008 ~ % cat /lib/systemd/system/fancontrol.service
[Unit]
Description=fan speed regulator
# Run pwmconfig to create this file.
ConditionPathExists=/etc/fancontrol
After=lm-sensors.service
Documentation=man:fancontrol(8) man:pwmconfig(8)
[Service]
ExecStartPre=/usr/sbin/fancontrol --check
ExecStart=/usr/sbin/fancontrol
PIDFile=/var/run/fancontrol.pid
[Install]
WantedBy=multi-user.target
/etc/fancontrol is the correct config file with the correct settings.
The thing is, it gets the correct settings from a cold boot or reboot, but not from a resume of suspend-to-ram.
Based on that, I don't think it's a problem with the fancontrol service file.
What's the target that happens when we resume?
This is, first, after resume from suspend (with wrong fan speeds), and then after restarting fancontrol:
--- bava 5018 ~ % systemctl status fancontrol
● fancontrol.service - fan speed regulator
Loaded: loaded (/lib/systemd/system/fancontrol.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2015-11-28 09:21:58 EST; 44min ago
Docs: man:fancontrol(8)
man:pwmconfig(8)
Main PID: 389 (fancontrol)
CGroup: /system.slice/fancontrol.service
├─ 389 /bin/bash /usr/sbin/fancontrol
└─6932 sleep 10
--- bava 5019 ~ % sudo systemctl restart fancontrol
--- bava 5020 ~ % systemctl status fancontrol
● fancontrol.service - fan speed regulator
Loaded: loaded (/lib/systemd/system/fancontrol.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2015-11-28 10:07:19 EST; 5s ago
Docs: man:fancontrol(8)
man:pwmconfig(8)
Process: 7058 ExecStartPre=/usr/sbin/fancontrol --check (code=exited, status=0/SUCCESS)
Main PID: 7222 (fancontrol)
CGroup: /system.slice/fancontrol.service
├─7222 /bin/bash /usr/sbin/fancontrol
└─7429 sleep 10
I think the issue is that fancontrol.service is only set to trigger on multi-user.target, whereas it should also trigger after suspend.target:
[Install]
WantedBy=multi-user.target suspend.target
How do I safely make this change without getting hosed by future updates from the package?
I would have less of a problem with systemd if the documentation was better (or, in many cases, existed at all).
This is the best I can determine:
--- bava 5017 systemd/system % sudo mkdir /etc/systemd/system/suspend.target.wants
--- bava 5020 systemd/system % sudo cp /lib/systemd/system/fancontrol.service /etc/systemd/system/suspend.target.wants/
--- bava 5024 system/suspend.target.wants % sudo sed -i 's/WantedBy=multi-user.target/WantedBy=multi-user.target suspend.target/g' /etc/systemd/system/suspend.target.wants/fancontrol.service
--- bava 5026 system/suspend.target.wants % sudo systemctl daemon-reload
Nope.
Fine.
I'll try editing the package's service file.
--- bava 5044 systemd/system % sudo sed -i 's/WantedBy=multi-user.target/WantedBy=multi-user.target suspend.target/g' /lib/systemd/system/fancontrol.service
--- bava 5045 systemd/system % sudo systemctl daemon-reload
Nope. God damn it.
Piece of shit systemd.
https://bugs.launchpad.net/ubuntu/+source/lm-sensors-3/+bug/489596
Edited /lib/systemd/system/fancontrol.service to add this under the [Service] section:
Restart=always
Fucking nope.
Spent more time fucking around with this, but nothing seems to work.
systemd just does what it wants. Any changes to the service file don't make a difference.
One odd thing is that `systemctl list-units --type=target --all` doesn't show any kind of suspend/resume/sleep target.
But `systemctl list-unit-files | grep suspend` show a suspend target. Maybe the above is just for non-builtin targets?
https://plus.google.com/+KimKr%C3%B6ger/posts/DFnhetzASeK
systemd-suspend.service(8):
Immediately before entering system suspend and/or hibernation systemd-suspend.service (and the other mentioned units, respectively) will run all executables in
/lib/systemd/system-sleep/ and pass two arguments to them. The first argument will be "pre", the second either "suspend", "hibernate", or "hybrid-sleep"
depending on the chosen action. Immediately after leaving system suspend and/or hibernation the same executables are run, but the first argument is now "post".
All executables in this directory are executed in parallel, and execution of the action is not continued until all executables have finished.
Note that scripts or binaries dropped in /lib/systemd/system-sleep/ are intended for local use only and should be considered hacks. If applications want to be
notified of system suspend/hibernation and resume, there are much nicer interfaces available.
Created `/lib/systemd/system-sleep/fancontrol.sh` and made it executable:
#!/bin/sh
case $1/$2 in
post/*)
systemctl restart fancontrol.service
;;
esac
Holy shit, that seems to have done it!
Too bad systemd itself seems incapable of reliably restarting a service after suspend, and it takes this "hack".
(And all the systemd apologists blame this on fancontrol. May so or maybe not, but fancontrol behaved correctly under SystemV init.)
< ^ txt