[gentoo-user] Re: systemd questions: hdparm unit file, OpenRC packages

[Kai Krakow]

Am Mon, 10 Apr 2017 10:48:48 -0400
schrieb Rich Freeman <rich0@g.o>:

> On Mon, Apr 10, 2017 at 3:27 AM, Raffaele Belardi
> <raffaele.belardi@××.com> wrote:
> > After 10+ years of LXDE/OpenRC I decided to give Gnome/systemd a
> > try.
> >
> > 1. With OpenRC I used hdparm to put an external USB disk to sleep:
> >
> > $ cat /etc/conf.d/hdparm
> > sdb_args="-S24"
> >
> > Looks like systemd does not provide a unit file for hdparm yet,
> > right? If so I suppose I'll have to write my own.
> > In general I suppose the same holds for everything that was under
> > /etc/local.d/
>
> As Kai pointed out there are units/generators to run the stuff under
> local.d.  You could certainly create a unit for hdparm but a local.d
> script is probably fine for something done once like this, especially
> if there is no need to maintain any kind of state and undo it later.

KISS principle... ;-)

> > 2. Which OpenRC-related packages can I unmerge?
> > - sys-apps/sysvinit
> > - sys-apps/openrc

Oh I totally left that out...

> This stuff ends up being pulled in by the system set, but you can
> eliminate it if you create a symlink from /lib/gentoo/functions.sh to
> /etc/init.d/functions.sh.

I instead made a file there with the following contents to spot the
broken packages:

$ cat /etc/init.d/functions.sh
source /lib/gentoo/functions.sh
ewarn "Usage of /etc/init.d/functions.sh is deprecated"

>  Don't ask me why stuff STILL sources the
> old location, other than it being so trivial that nobody cares that
> much.  I've put openrc in package.provided just to avoid the needless
> upgrades.  You can ditch sysvinit if you set USE=sysv-utils on systemd
> (so that you still get stuff like reboot/halt/poweroff, though I'm not
> sure how essential those actually are these days).

Use the following instead if you don't want to fiddle around with
versioning in package.provided:

$ cat /etc/portage/profile/packages
-*sys-apps/openrc

This removes openrc from the system set. You can then use depclean to
get rid of the rest but carefully check not to remove essential stuff.

Thus, I also strongly recommend USE=sysv-utils.

This is something like:

> > - app-admin/sysklogd
>
> Never used it, so obviously you can live without that.

Indeed not needed.

> > - cron/anacron after transition to systemd timers
>
> You might want to also look at sys-process/systemd-cron as a bridge.
> It basically generates timer units from your crontab and also runs the
> stuff in /etc/cron.*.d/.  But, timer scripts also work just fine and I
> do that for stuff that I want a bit more control over.

I don't suggest so. Services don't spawn session which cronjobs may
depend upon (most don't, tho). Cron spawns a session in the system
context. Both is not the same, so you should carefully decide which
cronjob to convert to a timer. Everything in /etc/cron* should work,
but timers are not a replacement for cron.

> > - sys-apps/debianutils provides savelog functionality also provided
> > by systemd but also installkernel so I shall not remove it
>
> I use logrotate personally, and I still need it for stuff that doesn't
> use syslog.

I've ditched all oldschool text log and only use journal now. This made
logrotate obsolete (which hardly managed to get all logfiles correctly
anyways due to changes in packages default configuration).

> > - others?
>
> That depends how far down the rabbit hole you want to go.  Systemd has
> semi-replacements for stuff like ntpd, dns, etc.  They're not intended
> as full replacements.  If you're serving time/dns/etc then you
> probably won't want it.  If you just want something to manage it
> locally on the host then these are fairly viable replacements.  There
> is also networkd, which I use on systems that don't have wifi.

All replacements except systemd-resolved work flawless for me. I'm
currently using the systemd resolver but it has its hickups from time
to time. This has become much better with the latest systemd version.

All those services are well integrated with each other and suitable for
most stuff. Tho, systemd-networkd is not explicitly developed as a
desktop daemon currently, systemd folks still tend to recommend
NetworkManager to get all features. The systemd replacement perfectly
works for me, tho: My desktop PC is a stationary PC with wired network.
If you're mobile or use wifi, ymmv.

> Systemd basically tries to provide all the essential services from a
> client-only perspective.

Yes, and that's sufficient. It doesn't have to be a server, meta
server, or proxy server. And it shouldn't be.

-- 
Regards,
Kai

Replies to list-only preferred.