Dietpi: [Question] Do we need "libpam-systemd" + "dbus"?

[MichaIng]

I was looking around my dietpi system and again fell over the dbus-daemon running, asking myself if anything is actually using dbus. dbus-monitor --system reveals so far phpsession cleanup to throw some messages there, but I doubt that they are necessary for anything:

signal time=1506857946.638233 sender=:1.0 -> destination=(null destination) serial=4706 path=/org/freedesktop/systemd1/unit/phpsessionclean_2etimer; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "org.freedesktop.systemd1.Timer"
   array [
      dict entry(
         string "NextElapseUSecRealtime"
         variant             uint64 1506859740000000
      )
      dict entry(
         string "NextElapseUSecMonotonic"
         variant             uint64 0
      )
      dict entry(
         string "LastTriggerUSec"
         variant             uint64 1506857945989332
      )
      dict entry(
         string "LastTriggerUSecMonotonic"
         variant             uint64 601606588714
      )
      dict entry(
         string "Result"
         variant             string "success"
      )
   ]
   array [
      string "TimersMonotonic"
      string "TimersCalendar"
   ]

Actually libpam-systemd depends on dbus and systemd itself at least recommends it.

I do not understand too much and deep enough about this, but a bid research brings, that dbus is mostly used for desktop environments, e.g. also dietpi installs dbus-x11 together with the related desktop. So my question is, what libpam-systemd actually does and if it can be removed together with dbus safely from a pure headless server system.

I read the package description of all these packages, but I would appreciate if someone would find more linux noob friendly words to explain the actually benefit, in case for a pure server environment.

[MichaIng]

I did some research here and there and the libpam-systemd package starts the systemd-logind service and registers user sessions to it. There they can be scanned and manipulated by other pieces of software, which then need to depend on the package.

I didn't find any hint that package and service themselves provide any passive advantages, thus we should be able to remove them from default DietPi dependencies. But of course I am not sure whether some DietPi script does use the services features. Searching for "logind" and things like this inside the repos files does not give any hits.

I removed the package together with dbus (dependency) two days ago and so far do not recognize any issue.

[Fourdee]

@MichaIng

I can see this opening a huge can of worms lol. Maybe not now, but down the line.

Generally speaking, if we are not 100% sure what each of those packages do, and in what instances we would need them, I think its best we leave them in for now.

If we can achieve the above, then we can investigate.

[MichaIng]

If logind is not available, a systemd service starts 5 additional agetty processes (VTs): tty2 - tty6

Logind seems to allow that they are created/removed on demand. If we assume general SSH login and just in emergency cases login directly to the SBC, the service can be masked to remove the additional processes: systemctl mask getty-static.service

https://unix.stackexchange.com/questions/56531/how-to-get-fewer-ttys-with-systemd

[Fourdee]

@MichaIng

Currently we disable getty 2-6:
https://github.com/Fourdee/DietPi/blob/master/PREP_SYSTEM_FOR_DIETPI.sh#L448-L450

[MichaIng]

I am not too deep inside this, but I guess the services DietPi already disables, are related to systemd-logind, which enables a tty creation on demand, if I understood right. The service I mentioned above is not active while logind active. It just got activated after removing libpam-systemd/thus logind to provide 6 ttys for just in case, since they can not be created anymore on demand. For pure ssd/terminal systems this is of course not necessary. I run now my Pi2 and x86 VM without logind successful for a while.

But if we want to remove it for DietPi we should make sure that it will be reinstalled together with any desktop again. I guess this needs much testing and clarifications and I will take care about Nextcloud installation now first and about cleaning up manual marked packages second :wink:.

Mark as low priority or close, as you wish.

[MichaIng]

systemd-timesyncd/timedatectl also needs dbus to start, which is offered as ntp option by DietPi. Another argument to keep it, and who knows which other systemd services depend on it/logind. We should really keep things as they are to prevent further surprises. Will mark as closed...