DietPi-Set_Hardware | RPi: Disable serial console

[MichaIng]

Current implementation: https://github.com/Fourdee/DietPi/blob/testing/dietpi/func/dietpi-set_hardware#L1452-L1482

At least on my RPi2, this somehow didn't work on Stretch nor Buster. The service/process restarts itself, no matter if stopped or even disabled. Maybe it has something to do with its arguments:
/lib/systemd/system/[email protected]

ExecStart=-/sbin/agetty -o '-p -- \\u' --keep-baud 115200,38400,9600 %I $TERM
Type=idle
Restart=always
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes

In my case the only thing helped was: systemctl mask [email protected]
Can someone verify? In case we could just switch enable/disable by unmask/mask, or do this on top.

[Fourdee]

@MichaIng

Quick test on fresh install RPi3 Debian Stretch, appears disabled for me:

root@DietPi:~# systemctl status serial*
root@DietPi:~# systemctl status getty*
● getty.target - Login Prompts
   Loaded: loaded (/lib/systemd/system/getty.target; static; vendor preset: enabled)
   Active: active since Wed 2018-02-07 16:21:23 GMT; 1h 29min ago
     Docs: man:systemd.special(7)
           man:systemd-getty-generator(8)
           http://0pointer.de/blog/projects/serial-console.html

Feb 07 16:21:23 DietPi systemd[1]: Reached target Login Prompts.

● [email protected] - Getty on tty1
   Loaded: loaded (/lib/systemd/system/[email protected]; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/[email protected]
           └─noclear.conf
   Active: active (running) since Wed 2018-02-07 16:21:23 GMT; 1h 29min ago
     Docs: man:agetty(8)
           man:systemd-getty-generator(8)
           http://0pointer.de/blog/projects/serial-console.html
 Main PID: 967 (agetty)
   CGroup: /system.slice/system-getty.slice/[email protected]
           └─967 /sbin/agetty --noclear tty1 linux

@MichaIng

Whats in your /boot/cmdline.txt?

[MichaIng]

@Fourdee
dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=21728f0a-02 rootfstype=ext4 elevator=deadline fsck.mode=force fsck.repair=yes rootwait
No AMA0 inside.

Can you verify via htop, that agetty ttyAMA0 task is not present?

[Fourdee]

@MichaIng

agetty is there, but only running for tty1:

systemctl disable [email protected]
reboot

Removes tty1 and agetty.

From what I remember, tty1 is an additional screen which can be switched locally. We left 1 in for a means to switch screens when the original locks up (eg: xinit program gone wrong) and non-ssh :
https://askubuntu.com/questions/467912/how-do-i-log-in-in-tty1

[MichaIng]

@Fourdee
Hmm okay, then I am not sure what I made wrong/different. Maybe due to I purged dbus. In that case getty-static.service jumps in:

[Unit]
Description=getty on tty2-tty6 if dbus and logind are not available
ConditionPathExists=/dev/tty2
ConditionPathExists=!/lib/systemd/system/dbus.service

[Service]
Type=oneshot
ExecStart=/bin/systemctl --no-block start [email protected] [email protected] [email protected] [email protected] [email protected]
RemainAfterExit=true

Thus I need to disable/mask that one to prevent additional agettys. Maybe that also triggers the serial getty somehow.

I just found that: https://stackoverflow.com/questions/21596384/cannot-disable-systemd-serial-getty-service

Seems that those gettys are forced, if non dbus is present. Will investigate that later.

This is another topic but I found that all software I use runs fine without any dbus/logind active. This are 2 tasks less :D.

Since we don't preinstall libpam-systemd, logind seems useless anyway: https://packages.debian.org/de/stretch/libpam-systemd

Thus no package remains that depends on dbus.

---

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

So it seems:

• If dbus is present, logind starts and handles spawning of gettys on demand.
• If dbus is not present, logind does not start and getty-static.service is started instead, to spawn 5 additional getties precautionary. This is handled by systemd-getty-generator and overwrites enabled/disabled states of that service, thus you need to mask or overwrite it via /etc/systemd/system/getty-static.service.
• I didn't find the exact prove/reference for this, but it seems that also the serial-getty.service is forced by getty generator, if no logind (without dbus) handles the spawning on demand. At least serial getty seems one main task of getty generator: https://manpages.debian.org/jessie/systemd/systemd-getty-generator.8.en.html

=> So, if dbus is removed, thus logind doesn't start, you need to prevent gettys from starting the hard way, by masking or overwriting them in /etc/systemd/system.

---

About tty1:
If I am not wrong, this is necessary to have access to local console? Also boot console is printing to tty1 as of cmdline.txt. So this should be never disabled, if you ever want to have emergency access to server directly, e.g. if SSH fails? Framebuffer, HDMI output can be in case adjusted via config.txt/dietpi.txt on desktop, if necessary (headless configuration), but actually even that I always configured my Pi headless, plugging an actual monitor always lead to correct output, maybe due to some active triggers.

[Fourdee]

@MichaIng

tty1 this is necessary to have access to local console?

Correct, confirmed unable to login lol 👍

[MichaIng]

@Fourdee
Do you know any reason to keep dbus, if we manage to mask the getty services instead? I read here and there about "headless/server, thus without dbus/logind, and looks like all this is mostly needed for desktops, where the related packages then anyway will have dbus as dependency.

As it is the "system" message bus, I don't think, that any end user software directly use/need it. But though it would need testing for at least all our non APT-package titles. But I did never faced issues so far with all I use/tested (have dbus uninstalled on all test servers).

[Fourdee]

@MichaIng

Do you know any reason to keep dbus, if we manage to mask the getty services instead?

Not that i'am aware of.

Ok, lets go ahead and remove it for fresh installs ! .installed -f check and PREP. Only way we'll really know if any issues are created by its removal across systems?

[MichaIng]

@Fourdee
At least on PREP it should be save to apt-mark auto and leave it for G_AGA.
About fresh installs, you are thinking to remove on 1st run updates? G_AGP would be maybe a bid risky, if not all devices get their system packages from official Debian repo? But you know better. For kernel/firmware dbus should be not necessary, it seems indeed a system(d)/init thing and at least for Debian repo systemd (etc) it is not "necessary".

We could just apt-mark auto also on 1st run update, but then it would stay in place on most systems, as recommendation of systemd.
You once mentioned, that on some of our devices, recommendations are not installed/are autoremoved by default? In that case it would be anyway an idea to align our devices about this. Core (PREP) DietPi already comes without any recommendations.

[Fourdee]

@MichaIng

G_AGP would be maybe a bid risky

Agree 👍 As some devices have additional packages, may pre-req dbus etc.

For now, we should simply remove dbus from PREP only.

You once mentioned, that on some of our devices, recommendations are not installed/are autoremoved by default?

End of PREP, once /etc/apt/apt.conf.d/99-dietpi-norecommends is removed:

In terms of G_AGI and dietpi-software, we manually add --no-install-recommends as additional option, for some software titles, where the recommends are simply not required. So its a manual option we control.
G_AGP/G_AGA will remove recommends.

[MichaIng]

@Fourdee
As far as I understood once, on some devices (their base images) there is already preinstalled /etc/apt/apt.conf.d/norecommends file. Just found it: https://github.com/Fourdee/DietPi/issues/1146#issuecomment-329199405

[Fourdee]

@MichaIng

As far as I understood once, on some devices (their base images) there is already preinstalled /etc/apt/apt.conf.d/norecommends file.

Good spot 👍

We should remove those from all images, keep everything standardized.

00recommends on Odroid N1, so coverall would be,

rm /etc/apt/apt.conf.d/*recommends*

[MichaIng]

@Fourdee
Remove those, or skip recommendations on all devices (skip the removal of our own norecommends config in PREP), that's the question, you know I always vote for less 😆.
Otherwise also dbus would stay: recommendation of systemd, as it is basis for logind

I run my Pi (and VMs) like this nearly since start. The only one I needed to install manually was iptables for fail2ban, the time I still used it: https://packages.debian.org/de/stretch/fail2ban
But as I know now, fail2ban has several other possibilities for blocking.

[Fourdee]

@MichaIng

Yep, this needs further review.

All Odroids contain:

APT::Install-Recommends "0";
APT::Install-Suggests "0";

RPi is default to include recommends.
Sparky Stretch is no recommends.

---

Ok, so in regards to setting no recommends by default:

• We are covered for Jessie
• Covered for Stretch
• RPi is the only possible issues we may experience. But we can always fix them.

The only way we'll cover all our software installs, is to roll this out for end users.

@MichaIng

Agree to try disabling recommends/suggests on all our images by default?

[MichaIng]

@Fourdee
Jep, agree. The risk for issues on RPi is anyway small, since Raspbian and Debian repos are mostly the same, with same dependencies and recommends.

[MichaIng]

@k-plan
Do you have a RPi2 for testing there? Last check about this topic is, if after purging dbus + reboot and with disabled serial console (default), getty ttyAMA0 process does not show up by itself. So actually the initial question of this issue 😆.

Maybe I did something else different/wrong on my RPi2, but I needed to mask [email protected] to get rid of the serial getty process.

[Fourdee]

@MichaIng

^^ with commits above to mask

🈯️ RPi 3 test disable:

• /DietPi/dietpi/func/dietpi-set_hardware serialconsole disable
• reboot
  

🈯️ RPi 3 test enable:

• /DietPi/dietpi/func/dietpi-set_hardware serialconsole enable
• reboot
  

@MichaIng

Looks resolved, I believe we can mark this as closed? 😃

[MichaIng]

@Fourdee
Nice one, I played around with unmask/mask/enable/disable behave:

2018-02-28 23:08:36 root@micha:~# systemctl enable serial-getty@ttyAMA0
Failed to enable unit: Unit file /etc/systemd/system/[email protected] is masked.
2018-02-28 23:08:58 root@micha:~# systemctl unmask serial-getty@ttyAMA0
Removed /etc/systemd/system/[email protected].
2018-02-28 23:09:17 root@micha:~# systemctl enable serial-getty@ttyAMA0
Created symlink /etc/systemd/system/getty.target.wants/[email protected] → /lib/systemd/system/[email protected].
2018-02-28 23:09:22 root@micha:~# systemctl mask serial-getty@ttyAMA0
Created symlink /etc/systemd/system/[email protected] → /dev/null.
2018-02-28 23:09:41 root@micha:~# l /etc/systemd/system/getty.target.wants/
total 0
lrwxrwxrwx 1 root root 34 Nov 29 02:10 [email protected] -> /lib/systemd/system/[email protected]
lrwxrwxrwx 1 root root 41 Feb 28 23:09 [email protected] -> /lib/systemd/system/[email protected]
2018-02-28 23:09:54 root@micha:~# systemctl disable serial-getty@ttyAMA0
Unit /etc/systemd/system/[email protected] is masked, ignoring.
2018-02-28 23:10:12 root@micha:~# systemctl unmask serial-getty@ttyAMA0
Removed /etc/systemd/system/[email protected].
2018-02-28 23:10:20 root@micha:~# systemctl disable serial-getty@ttyAMA0
Removed /etc/systemd/system/getty.target.wants/[email protected].
2018-02-28 23:10:22 root@micha:~# systemctl mask serial-getty@ttyAMA0
Created symlink /etc/systemd/system/[email protected] → /dev/null.
2018-02-28 23:10:26 root@micha:~# l /etc/systemd/system/getty.target.wants/
total 0
lrwxrwxrwx 1 root root 34 Nov 29 02:10 [email protected] -> /lib/systemd/system/[email protected]

If service is masked, but not disabled, symlink at /etc/systemd/system/getty.target.wants/ stays. I don't know if this could cause warnings/error messages at boot or something, but just in case, I add disabling before masking: https://github.com/Fourdee/DietPi/commit/bd658006cd786f16895aa48850ab0202d78ab661

There should be a lot of messages about the non existent services right now, don't they? Add &> /dev/null or 2> /dev/null?
Or do it a bid device specific? Just handle AMA0 for RPi e.g.?

[Fourdee]

@MichaIng

There should be a lot of messages about the non existent services right now, don't they? Add &> /dev/null or 2> /dev/null?

2> /dev/null 👍

I wouldn't bother with device specific.
Devices have changed the serial tty name in the past, and if we add new devices, its another factor we need to verify.
Unless we want to add additional testing/maintenance, simply run all to cover all known possibilities.

[MichaIng]

@Fourdee
Sounds reasonable, will add commit: https://github.com/Fourdee/DietPi/commit/c3626d2154754db4e50f4bb81d1621bc0336b0e4

[Fourdee]

@MichaIng

Sounds reasonable, will add commit: c3626d2

Legend, thanking you 👍

Issue is now resolved. Marking as completed.