< ^ txt
Wed Nov 29 09:34:27 EST 2017
Slept from ten-thirty to seven. Woke briefly around five.
Forty-three and sunny today.
Work:
- Check on HZ backup
Done.
- Help Scott pull old server from rack
Done.
- Label new SSD's in Zol
Done.
- Check on mdadm RAID reporting
Done.
- Review invoices
Done.
- Work on MECS
No.
Twenty-five-minute walk at lunch.
Nice out, but not a glorious and warm as yesterday.
Saw a trio of crows.
Did a fresh install of Debian of Zol, with its new SSD RAID 10.
Home:
- Go study
Done.
- Wait, does i3lock lock after resume from suspend? I probably need to make it happen.
Done.
Stopped on my way home from work to pick up a few groceries at Target.
I created `$HOME/.config/systemd/user/sleeplock.service`:
[Unit]
Description=Lock the screen for suspend/wake
Before=sleep.target
[Service]
Type=forking
Environment=DISPLAY=:1
ExecStart=/usr/bin/i3lock -e -f
[Install]
WantedBy=sleep.target
And:
$ systemctl --user daemon-reload
$ systemctl --user enable sleeplock
$ systemctl --user status sleeplock
Note: double-check your value of $DISPLAY (is it ":0" or ":1"?).
Unfortunately, the above unit never runs. Why?
https://unix.stackexchange.com/questions/149959/how-to-run-systemd-user-service-to-trigger-on-sleep-aka-suspend-hibernate
> sleep.target is specific to system services. The reason is, sleep.target is not a magic target that automatically gets activated when going to sleep. It's just a regular target that puts the system to sleep – so the 'user' instances of course won't have an equivalent. (And unfortunately the 'user' instances currently have no way to depend on systemwide services.)
Well, that's annoying.
Instead:
# apt-get install xss-lock
$ xss-lock /usr/bin/i3lock &
That works.
I added `xss-lock $HOME/bin/xlock &` to my `.xsession`.
Breakfast: sausage and egg sandwich, cafe latte
Lunch: falafel bowl, coffee
Dinner: carrots, chips
< ^ txt