For the longest time, the systemd "user" daemon ran nothing other than something that called itself (sd-pam).
Now I see a vast forest or utter crap being started by the systemd user daemon. Most of this is stuff I long ago eradicated, and now it is pulled it back in.
Where the devil does systemd stash the info about what crap to start in the "user daemon" and how do I change it?
2080 ? Ss 0:00 /usr/lib/systemd/systemd --user 2083 ? S 0:00 _ (sd-pam) 2111 ? Ss 0:00 _ /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation 2235 ? Ssl 0:00 _ /usr/libexec/at-spi-bus-launcher 2240 ? S 0:00 | _ /bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 2243 ? Sl 0:00 _ /usr/libexec/at-spi2-registryd --use-gnome-session 2292 ? Ssl 0:00 _ /usr/libexec/gvfsd 2297 ? Sl 0:00 _ /usr/libexec/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes 4646 ? S 0:00 _ /usr/libexec/gconfd-2 6157 ? Sl 0:00 _ /usr/bin/gnome-keyring-daemon --start --foreground -- components=secrets
I utterly despise the rancid gnome virtual filesystems nonsense. I previous managed to make it go away, but now it is back.
I hate the gnome-keyring-daemon, and it is back too (and comes back again when I kill it - no doubt courtesy of systemd).
AAAAAAAGGGGGGGHHHHHHH!!!!!!!!
On Tue, 6 Sep 2016 08:06:37 -0400 Tom Horsley wrote:
Where the devil does systemd stash the info about what crap to start in the "user daemon" and how do I change it?
OK, I spent all day figuring this out, and have successfully eradicated the gnome-keyring-daemon startup. Complete write-up here:
http://tomhorsley.com/game/punch.html#User%20Daemons
I couldn't figure out how individual users can control things, but at least I can eradicate things across all user sessions.
On Tue, Sep 06, 2016 at 08:17:49PM -0400, Tom Horsley wrote:
On Tue, 6 Sep 2016 08:06:37 -0400 Tom Horsley wrote:
Where the devil does systemd stash the info about what crap to start in the "user daemon" and how do I change it?
OK, I spent all day figuring this out, and have successfully eradicated the gnome-keyring-daemon startup. Complete write-up here:
http://tomhorsley.com/game/punch.html#User%20Daemons
I couldn't figure out how individual users can control things, but at least I can eradicate things across all user sessions.
Oh Tom, I went and read that page (and the Big Hammer page) and could hardly stop laughing! I feel your pain, some of the same things bug me too, but the way you describe them is hilarious!
On 09/06/2016 05:06 AM, Tom Horsley wrote:
Where the devil does systemd stash the info about what crap to start in the "user daemon" and how do I change it?
Arch has a pretty good document on the topic:
On Tue, 6 Sep 2016 17:25:22 -0700 Gordon Messmer gordon.messmer@gmail.com wrote:
On 09/06/2016 05:06 AM, Tom Horsley wrote:
Where the devil does systemd stash the info about what crap to start in the "user daemon" and how do I change it?
This seems to be in these files,
Similarly to system units, user units are located in the following directories (ordered by ascending precedence):
/usr/lib/systemd/user/ where units provided by installed packages belong. ~/.local/share/systemd/user/ where units of packages that have been installed in the home directory belong. /etc/systemd/user/ where system-wide user units are placed by the system administrator. ~/.config/systemd/user/ where the user puts its own units.
Arch has a pretty good document on the topic:
Thanks Gordon, that was a well organized read. After reading that page, and the systemd page there as well, it sounds like what Tom wants is to disable any systemd units unless they are specifically activated. Like this description for system targets, except for user targets. Maybe replacing disable with mask, so updates don't enable them.
From their systemd wiki page:
""" Arch Linux ships with /usr/lib/systemd/system-preset/99-default.preset containing disable *. This causes systemctl preset to disable all units by default, such that when a new package is installed, the user must manually enable the unit.
If this behavior is not desired, simply create a symlink from /etc/systemd/system-preset/99-default.preset to /dev/null in order to override the configuration file. This will cause systemctl preset to enable all units that get installed—regardless of unit type—unless specified in another file in one systemctl preset's configuration directories. User units are not affected. See the manpage for systemd.preset for more information. """
And now I'm tempted to experiment with running X as a systemd --user process, which I think is how Tom is running his graphical environment.
-
Fred Smith -
Gordon Messmer -
stan -
Tom Horsley