managers: system, session, window, volume, preference (and some use a display)

Links: using systemd as a session manager ::

---

I miss the SysV days when system, session, window (eg. "compositing"), volume, preference, and display managers were all cleanly defined. In fact, we never even needed the preference manager, gconf, because configurations were done with simple text files for each app. I'm just a regular user, and it takes me a lot of work these days to keep these managers separate or find their configuration files. They also seem to intertwine on occasion, requiring detangling time, as well.

Display Manager Disclaimer

Logins, startx, and shutdown are the only terminal commands needed in a normal session. Display Managers are only needed to make these more aesthetic. Accordingly, I haven't used a display manager in ten years. Why have an aesthetic login if it costs memory and potential fails? Second, not using it removes one variable from the kludge of 6 managers just listed above. Display Managers inadvertently obscure any start-up fails by keeping text log access out of sight. That's a problem during an install. In fact, during installs, I obtain a solid Runlevel 2 before downloading any X elements.

Session manager sussed-out

I attempted to tweak Evince's default zoom level the other day without gvfs (gnome's volume manager) installed. Sadly, Evince does not use old-skool config files; users have to set "schema keys", which are probably xml files. At any rate, one starts at the top, the correct schema, and then one modifies its key: find the schema, then its possible keys. To shorten the codeblock below, here were the two Evince-related schemas using the list-schema flag :

$ gsettings list-schemas
org.gnome.Evince.Default
org.gnome.Evince

And then the keys for those schemas.

$ gsettings list-keys org.gnome.Evince
document-directory
auto-reload
override-restrictions
page-cache-size
allow-links-change-zoom
pictures-directory
show-caret-navigation-message

$ gsettings list-keys org.gnome.Evince.Default
window-ratio
continuous
fullscreen
show-toolbar
show-sidebar
dual-page-odd-left
inverted-colors
zoom
sidebar-page
sidebar-size
dual-page
sizing-mode

It appears the "zoom" key is the one to set, which is in schema Evince.Default.

$ gsettings set org.gnome.Evince.Default zoom 1.0
$ gsettings get org.gnome.Evince.Default zoom
1.0

We can see the zoom was set correctly (to 100%). Now let's run Evince:

$ evince
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files

Evince starts, but spawns the error above and only the default zoom factor, instead of the 100% zoom I entered.

Was gnome-session not running, sharing with systemd, or what? A simple setting can often means days of frustration in Linux. If I recall correctly, it's further the case, that gnome-session can only be started after dealing with PAM, like via gdm-password. It's unlikely any gnome sessions are running.

# ps -A |grep -i g
614 ? 00:00:00 gconfd-2
3602 pts/2 00:00:00 grep
31658 ? 00:00:00 gnome-pty-helpe

Now it's clear: no gnome-session is running. The gsetting commands were accepted. That is because, for the settings to be entered, only gconfd, gnome's preference manager, had to be running. However, there was no way to implement those preferences, because the session manager, gnome-session, was not running: an error message was generated. Meanwhile, Arch recommends against any gconf schemas, and notes they will soon be replaced with "dconf". Currently then, Evince is probably caught in the middle of these. We really have no way to configure Evince without getting a session manager going, which in turn probably requires the dreaded gvfs by the way.

Okular

In spite of the immense KDE libraries necessary for Okular, I have to look. I mean if I can just set preferences at this point, I'd be happy.

systemd: time-outs, journal size, Xorg terminals

I prefer SysVinit to Systemd, in the same way I prefer OSS to ALSA, and ALSA to PulseAudio: the newer stuff creates problems where there were none. Among these problems are locating configuration commands or files in the face of opaque memory or CPU hogging defaults.

time-outs

During shut down and start-up, systemd will wait too long to kill or initialize internet connections, among other things. Set the systemd time-out restrictions...

dhcpcd tries to initialize

After an update, dhcpcd occasionally is re-enabled at boot. Since it tries all interfaces, it will hang on any that are not connected. Furthermore, the process is partly obscured, so it's tricky to find. The standard "list-unit-files" does not give a complete syntax. So although one disables dhcpcd.service, the other service is not fully named and is cryptically called by a different name in boot.

# systemctl list-unit-files |grep dhcpcd
dhcpcd.service disabled disabled
dhcpcd@.service indirect disabled

$ systemctl status dhcpcd*@*.service
* dhcpcd@enp4s0.service - dhcpcd on enp4s0
Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Tue 2020-06-09 04:32:17 PDT; 7min ago
Process: 362 ExecStart=/usr/bin/dhcpcd -q -w enp4s0 (code=exited, status=1/FAILURE)

The name you need here is dhcpcd@enp4s0.service, it cannot be disabled as the first name given, simply dhcpcd@.service. To stop this hang...

# systemctl disable dhcpcd@enp4s0.service
Removed /etc/systemd/system/multi-user.target.wants/dhcpcd@enp4s0.service.

journald logs

Prior to systemd, boot-ups used to log to /var/log, pretty much auto-magically via rsyslog (syslog). The only thing one had to configure was chron's timeline for rotating old logs into the trash. Suckily, journald logs grow until they take over something like 10% of disk space by default. To me, it's yet another mistake of the last 8 years of Linux -- adding boggy new application layers instead of improving and simplifying long-standing daemons¹. At any rate, journald must be configured if you want anything reasonable and intelligible. Secondly, you must use "journalctl" the read them, because they are stored in a binary format.

Since there are about 30 settings in /etc/systemd/journald.conf, an hour is wasted researching journald's settings.

# nano /etc/systemd/journald.conf
Storage=auto
SystemMaxUse=200K

When I want an ASCII record for grepping, etc, I use journalctl -r -o short-iso ("r" reverses time to put most recent on top, "short-iso" is for giving normal clock timestamps), and save screen output to text:

$ journalctl -r -o short-iso 2>&1 file.txt

Alternatively, one can output other formats such as the apparently standard JSON format. It cannot however export directly to text unless it's to another application.

This the file when the system is running well and no logging is needed:

Storage=none

notes

• 200K of logging seems to cover about the last 10 boots.
• journalctl --verify checks logs for corruption

xorg terminals

If systemd is not restricted, it will open 40+ terminals when you open X, buring hundreds of unnecessary MB's of memory. Seven terminals is sufficient for operations inside X

# nano /etc/systemd/logind.conf
NAutoVTs=6

---

¹It's as stupid as when PulseAudio took hold of Alsa (which itself overlaid OSS)

power management - hibernation key(s)

I recently encountered a HP Pavilion for which a good friend wanted hibernation capacity. Ideally, hibernation would result from an idle state (eg., when a user steps away from their system for a number of minutes) and/or when hibernation was selected by the user (a menu item or a hotkey). The process gave me a chance to step through key bindings and power management configuration.

overview

I expected hibernation to really be two functions - hibernation, and resuming from hibernation, equally important. And both could have subsections which might include: 1) hardware settings (eg. having a swap file for suspending to a disk), 2) boot settings (eg. grub/lilo), 3) daemon settings for whatever daemon alerted the kernel (possibly many options), 4) key bindings 5) inactivity time-out.
NB: Currently having hardware issues with full hibernation, so this entry ends with "suspending". Upgrade to full hibernation downstream.

1. swap

For hibernation, a swap partition is the easiest, though supposedly a swap file can be configured with enough work. I checked in cfdisk, and noted that my friend had more than two gigs of swap partition on /dev/sda2. /Etc/fstab was properly configured as well. Otherwise, mkswap and swapon, possibly followed by a fresh genfstab, would be accomplished in this step.

2. boot

This guy is running ArchLinux with grub, so I looked here, followed by:

# nano /etc/default/grub
GRUB_CMDLINE_LINUX="resume=/dev/sda2"

# grub-mkconfig -o /boot/grub/grub.cfg

I got a couple of errors when updating grub, thanks apparently to this bug, but these cleared with an update to his system (pacman -Syu) the following day.

3. daemon

What to use to notify the kernel? Certainly, acpid and/or pm-utils are what most will choose. However, it's not necessary in this case. Arch's use of systemd already handles some power events without another daemon. Per this helpful page, I changed the login process, uncommenting the relevant hibernation line and restarting systemd:

# nano /etc/systemd/logind.conf
HandleHibernateKey=hibernate

# systemctl restart systemd-logind

No other daemons than systemd are needed with systemd installed. What's accomplished at this step is hibernate service enablement, but not activation. To activate through systemd we need a systemd service file telling it what to do, possibly a cron job, and possibly a key binding. Properly configured, the command to initiate hibernation is $ systemctl hibernate, and for suspension $ systemctl suspend. Select one of these to go through the configuration steps -- binding to a key, possibly, to a cron job, possibly a systemd service file, etc.

3a. privileges

One expects privilege confusion with users taking daemon actions, so a check of group membership is wise. On the other hand, according to this page about systemd, polkit is required for user privileges to run hibernation or suspend --- adding users to groups such as "disk" can actually cause conflicts. YMMV, it appears. In lieu of polkit, simply granting ourselves a specific privilege in /etc/sudoers, eg "username ALL=NOPASSWD: /usr/bin/systemctl", also should work.

4. keys

A non-standard KB-0630 enhanced keyboard with a separate hibernation key, so pretty sweet. Per this page, installed xbindkeys and hit the hibernation key.

$ xbindkeys -k
[hit the hibernate key]
"(Scheme function)"
m:0x0 + c:150
XF86Sleep

$ nano .xbindkeysrc
# Suspend system
"systemctl suspend"
XF86Sleep

$ nano .xinitrc (or .icewm/startup)
xbindkeys &

5. idle time

# nano /etc/systemd/logind.conf
IdleAction=suspend
IdleActionSec=20min

# systemctl restart systemd-logind

This worked, except that it would go to sleep in 20 minutes, idle or not.