Should DietPi-Config > Display > Headless also mask systemd-logind.service?

[thanhminhmr]

The systemd-logind.service are responsible for the local login prompt. In headless mode, there is no way to see the screen, so local login prompt is not necessary. Should the systemd-logind.service be masked then?

DietPi/dietpi/dietpi-config

Line 724 in b41029d

if [[ $G_WHIP_RETURNED_VALUE == 'Headless' ]]; then

[MichaIng]

Thanks for your suggestion.

No, systemd-logind.service is not responsible for the login prompt, getty@tty1.service is. systemd-logind.service would start additional login prompts on TTY2 - TTY6 if you switch to them, e.g. via F1 - F6 keys, but that is only a minor task of this service. It registers login sessions with systemd's PAM module, manages non-root (user and application) permissions via polkit for shutdown/reboot/hibernate, as well as for hardware key, of the host system but also e.g. for certain container engines. For details:
https://manpages.debian.org/systemd-logind

It is masked by default on DietPi and unmasked only either if the user actively sets a related dietpi.txt settings or installs programs via dietpi-software which do require it. Masking it again only when switching to headless mode will hence break something, unless dependant software was uninstalled again and the admin does not make manual use of the provided features.

We could add a dedicated option, which marks libpam-systemd as auto-installed, checks whether it is auto-removed (or directly checks whether dependants of it are installed), if so, offers to mask systemd-logind again while explaining the possible consequences. If an APT-installed application makes use of systemd-logind, it usually depends on libpam-systemd (required for mentioned PAM registrations). And if something depends on libpam-systemd, it is nearly assured to require systemd-logind.

[thanhminhmr]

So masking getty@tty1.service will prevent user from login locally, right?

[MichaIng]

Yes. It doesn't need to be masked but can be simply disabled. A little disk is that it's more difficult to revert in case there are network issues so that you need to login locally. Everything done currently, can be reverted via boot FAT partition from Windows/macOS, but enabling a service requires access to the ext4 root partition, i.e. doesn't work from external Windows or macOS systems. However, we do this already on images for SBCs without any video capabilities: fb2168c

Related PR for applying it on RPi with headless mode and further ideas what can be done: #2442

[thanhminhmr]

Thanks for the detailed explanation!