[conspire] systemd, grumble, grumble, ... (systemd annoyances)

[Michael Paoli]

systemd, grumble, grumble, ... (systemd annoyances)

Hmmmm, here's another one, not exactly "huge", but ... annoying.
# cd /var/tmp && TZ=GMT0 stat -c '%y %n' `ls -trd systemd-private*` |  
sed -e 's/\.[0-9]\{1,\} +0000 / /'
2017-11-30 13:12:08  
systemd-private-102a6c80239541b88ccb3a2cea5b0ff9-haveged.service-IbgkEk
2017-12-03 15:17:00  
systemd-private-f429c3e08a384325bbe4cab36c3064af-haveged.service-ymbKky
2017-12-03 15:17:02  
systemd-private-f429c3e08a384325bbe4cab36c3064af-apache2.service-xBk311
2017-12-03 15:35:24  
systemd-private-97bb0f1f5b60456b8a14be3542279344-haveged.service-u42Sky
2017-12-03 15:35:26  
systemd-private-97bb0f1f5b60456b8a14be3542279344-apache2.service-XaZsC2
2018-09-01 17:14:22  
systemd-private-08418923f6f7495ab7a8aa12fbfb7110-haveged.service-c9etWt
2018-09-01 17:14:32  
systemd-private-08418923f6f7495ab7a8aa12fbfb7110-apache2.service-YduYjS
2018-09-24 00:47:33  
systemd-private-88f06eb98e41440da68b7af01aa7ebd9-haveged.service-3EWRaC
2018-10-02 15:19:58  
systemd-private-88f06eb98e41440da68b7af01aa7ebd9-apache2.service-KhZRFW
2018-12-10 06:08:56  
systemd-private-a26f62af4d414a02bcafdb4b5f7ed0c3-haveged.service-iGfiUV
2018-12-10 06:08:57  
systemd-private-a26f62af4d414a02bcafdb4b5f7ed0c3-apache2.service-A4eCdL
2019-04-15 00:48:27  
systemd-private-990d75ed111a4606b5c5016195cd8bd1-haveged.service-LVKgrf
2019-04-15 00:48:29  
systemd-private-990d75ed111a4606b5c5016195cd8bd1-apache2.service-OZV8Ch
# TZ=GMT0 uptime
  01:30:40 up 6 days, 42 min,  9 users,  load average: 0.05, 0.02, 0.00
#

Now, WTF is systemd doing putting - and leaving - cruft in /var/tmp/ ?
Anyone with half a clue or more, writing stuff for Unix/Linux/BSD/...
should well know, per FHS, etc., that /var/tmp is non-volatile, and
contents thereof persist across reboots, and /tmp is essentially
volatile - does not persist across boots, or should be emptied
upon reboot - at least before going multi-user.  Seems rather clear
systemd lacks clue here.  What could it possibly need to write
to "temporary" or other stateful storage, that it would need or want to
have persist across boots? ... other than log stuff that it ought write
to files and/or syslog server(s) or such.  Ugh, ... looks like it's
relatively clueless about how to more properly start/stop/manage
services.  SysV init & friends never pulled that kind'a crud.
And any other stateful stuff - such as whether a service ought be
started or not upon reboot or going to certain run levels,
or its current state, ought be somewhere under /etc, or /var,
or /var/run ... not /var/tmp ... geez.
And, what, oh so incredibly useful stuff would it put in there that
it might possibly need across reboots?
# find systemd-private* ! -type d -print
# (for d in systemd-private*; do (cd "$d" && find . -print); done) | sort -u
.
./tmp
#
Uh huh.

<sigh>

Reminds me of the suckiness of vim - e.g. littering *.sw[a-z] files
all over the bloody place, and being rather crud about cleaning up after
itself.  Proper vi (e.g. nvi) doesn't have that issue.  Heck, a proper vi,
and vi -r and you know about all the stuff to potentially recover for the
invoking user (or root, for all), ... but nvi ... yeah, just go lookin'
for every bloody *.sw[a-z] file in every directory everywhere that might
possibly apply, ... otherwise vi[m] -r might not bother to ever tell
you about 'em.

http://www.pathname.com/fhs/
http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES
http://www.pathname.com/fhs/pub/fhs-2.3.html#VARTMPTEMPORARYFILESPRESERVEDBETWEE