[sf-lug] sudo abuse, suspend/shutdown, and polkit

[Rick Moen]

Quoting aaronco36 (aaronco36 at SDF.ORG):

> Another problem related to this for optimizing SSDs, IMHO, is that
> according to both the Arch Wiki on Solid State Drives [2] and the
> Debian Wiki on SSD Optimization [3], the fstrim.service and
> fstrim.timer systemd unit files in the util-linux package _both_
> intimately depend upon using systemd as su :-\
> 
> While Rick M, Michael P, and others are of course welcome to step
> right in and correct or verify it, it seems that it's fairly tough
> to wean oneself of these systemd-dependent utilities; at least
> difficult for optimizing SSDs.

Um,... fstrim can and IMO should be run via a simple cron job in
/etc/cron.weekly/ .


Unit files indeed need systemd, because unit files are by definition 
systemd configuration files.  So, if you prefer not to have systemd, you
just do things in the bog-standard way instead of using unit files.

It's possible I'm missing something, but my possibly overly fatigued
mind parsed what you said as equating to 'One problem with not having
systemd is that systemd configuration files won't do anything without
systemd.'  Which, yeah, I guess, but huh?

I mean, yeah, if you were reliant solely on a Debian Wiki page that
presumes the use of systemd, I guess you'd be screwed if you had no idea
how to run a weekly job in a plain ol' crontab.  Fortunately, the entire
Internet hasn't drunk the Kool-Aid, and it's not exactly brain surgery
to make a cronjob (or copy someone else's work).  

I mean, seriously, the key skill of the 21st Century so far has been the
lazy person's use of Web search engines, right?  (That is _not_ intended
as personal criticism of any kind, and I'm aware that the important bit
is to guesstimate what to search for).  So, searching for

    fstrim cron debian

...finds
https://www.digitalocean.com/community/tutorials/how-to-configure-periodic-trim-for-ssd-storage-on-linux-servers
as the first hit, wherein the author suggests:

#!/bin/sh
#trim all mounted file systems which support it
/cron-bin/fstrim --all || true

...as /etc/cron.weekly/fstrim.  (Don't forget to make it executable.)
His notion of a /cron-bin directory is idiotic, but it shows the basic
idea otherwise, i.e., an unbelievably Neanderthal-simple cron job that
just runs executable 'fstrim' with te --all flag.

The binary's proably /sbin/fstrim , BTW.

(Anyway, don't need no steenkin' unit files.)



Another hit on the same Web search is
https://forums.fedoraforum.org/showthread.php?316911-FSTRIM-Cron-Job,
where someone has posted an example cron job for the same purpose that
looks needlessly complex to me, but otherwise OK.  As before, there is
one idiotic element, the bit where he runs the script via 'root's
crontab', which means the personal cron table of the root user.  That is
a classic bonehead system administration error:  All system
configuration files are supposed to be in /etc so that they're all in 
one place and the Principle of Least Surprise isn't violated by key
system functions being organised out of a non-system directory or file.
Personal crontabs, including those of the root user, are _not_ system
files.

The correct place for system cron jobs is in /etc/crontab or one of
/etc/cron.daily/, /etc/cron.weekly/, etc., as appropriate.

Dozens of other hits from that Web search give similar answers.


> OTOH and speaking of the Devuan Project, one of the posts on their
> derivates '[Miyo] How to set daily trim job? [SOLVED]'[4] seems to
> suggest that fstrim is best handled thru fstrim as a _Periodic_ TRIM
> through cron or anacron rather than via that systemd fstrim.timer
> option.

Um, exactly.

That doesn't help Akkana with suspend-to-RAM / suspend-to-disk, of
course.