Jump to content

Le Potato Serial Getty on ttys0 starts, stops restarts


HAm

Recommended Posts

I am running Armbian 5.38 LePotato Debian Stretch next 4.14.14 and noticing some weird activities going on.

When checking the syslog it was full of this stuff:

 

Feb 23 06:25:29 localhost systemd[1]: Stopped Serial Getty on ttyS0.
Feb 23 06:25:29 localhost systemd[1]: Started Serial Getty on ttyS0.
Feb 23 06:25:39 localhost systemd[1]: serial-getty@ttyS0.service: Service hold-o
ff time over, scheduling restart.
Feb 23 06:25:39 localhost systemd[1]: Stopped Serial Getty on ttyS0.
Feb 23 06:25:39 localhost systemd[1]: Started Serial Getty on ttyS0.
Feb 23 06:25:50 localhost systemd[1]: serial-getty@ttyS0.service: Service hold-o
ff time over, scheduling restart.
 

and this goes on forever.... filling the syslog with megabytes of text.

What is going on and how to stop it?

As far as I know there is no gadget attached to ttys0, I only have a keyboard, a DVB-T USB stick, CAT-5 ethernet cable and HDMI attached to the LePotato.

The DVB-T stick is used as an ADSB receiver on Dump1090-mutabilitu and fr24feed is used to upload decoded positions of airplanes to Flightradar24.com

 

Help?

Link to comment
Share on other sites

On 2/23/2018 at 4:57 PM, HAm said:

I am running Armbian 5.38 LePotato Debian Stretch next 4.14.14 and noticing some weird activities going on.

When checking the syslog it was full of this stuff:

 

Feb 23 06:25:29 localhost systemd[1]: Stopped Serial Getty on ttyS0.
Feb 23 06:25:29 localhost systemd[1]: Started Serial Getty on ttyS0.
Feb 23 06:25:39 localhost systemd[1]: serial-getty@ttyS0.service: Service hold-o
ff time over, scheduling restart.
Feb 23 06:25:39 localhost systemd[1]: Stopped Serial Getty on ttyS0.
Feb 23 06:25:39 localhost systemd[1]: Started Serial Getty on ttyS0.
Feb 23 06:25:50 localhost systemd[1]: serial-getty@ttyS0.service: Service hold-o
ff time over, scheduling restart.
 

and this goes on forever.... filling the syslog with megabytes of text.

What is going on and how to stop it?

As far as I know there is no gadget attached to ttys0, I only have a keyboard, a DVB-T USB stick, CAT-5 ethernet cable and HDMI attached to the LePotato.

The DVB-T stick is used as an ADSB receiver on Dump1090-mutabilitu and fr24feed is used to upload decoded positions of airplanes to Flightradar24.com

 

Help?

I haven't played with Armbian but ttyS0 is only present on Amlogic's kernel. On mainline kernel, it should be ttyAML0. It could be that there's no such device and the tty service is restarting due to it.

Link to comment
Share on other sites

19 minutes ago, Da Xue said:

I haven't played with Armbian but ttyS0 is only present on Amlogic's kernel. On mainline kernel, it should be ttyAML0. It could be that there's no such device and the tty service is restarting due to it.

Thank you for that Info! Now, my next question is:

How do I stop this and how do I prevent it from happening again when I reboot?

Link to comment
Share on other sites

It is ttyAML0 on these kernels, I had to check and make sure something didn't sneak through in the boot command line.  So far I'm not sure where it's coming from, /dev/ttyS0..S3 are present, so systemd is trying to do its work.  @Da Xue I don't have one of your images running, could you verify this isn't happening on it?  I'll dig into my u-boot next, but I don't think that's where it's coming from.

Link to comment
Share on other sites

32 minutes ago, TonyMac32 said:

It is ttyAML0 on these kernels, I had to check and make sure something didn't sneak through in the boot command line.  So far I'm not sure where it's coming from, /dev/ttyS0..S3 are present, so systemd is trying to do its work.  @Da Xue I don't have one of your images running, could you verify this isn't happening on it?  I'll dig into my u-boot next, but I don't think that's where it's coming from.

What's the output of `cat /proc/cmdline`? @HAm

Link to comment
Share on other sites

Mine is

 

root=/dev/mmcblk1p1 rootwait rootflags=data=writeback rw rootfstype=ext4 console=ttyAML0,115200n8 no_console_suspend consoleblank=0 fsck.repair=yes loglevel=5 net.ifnames=0

unless HAm has changed something, but that shouldn't matter as I see the same syslog complaints:

 

Feb 22 06:49:55 localhost systemd[1]: serial-getty@ttyS0.service: Service hold-off time over, scheduling restart.
Feb 22 06:49:55 localhost systemd[1]: Stopped Serial Getty on ttyS0.
Feb 22 06:49:55 localhost systemd[1]: Started Serial Getty on ttyS0.

over and over.

 

Extra tidbit:

crw--w---- 1 root tty       4,  64 Feb 23 22:17 ttyS0
crw-rw---- 1 root dialout   4,  65 Feb 23 22:17 ttyS1
crw-rw---- 1 root dialout   4,  66 Feb 23 22:17 ttyS2
crw-rw---- 1 root dialout   4,  67 Feb 23 22:17 ttyS3

I'm a bit confused as I haven't done anything with the tty's on this, other than allowing root login via ttyAML0.

Link to comment
Share on other sites

3 hours ago, Da Xue said:

What's the output of `cat /proc/cmdline`? @HAm

Here it is, I hope it is useful.

oh6my@adsb-rx:~$ cat /proc/cmdline
root=/dev/mmcblk1p1 rootwait rootflags=data=writeback rw rootfstype=ext4 console=ttyAML0,115200n8 no_console_suspend consoleblank=0 fsck.repair=yes loglevel=5 net.ifnames=0
oh6my@adsb-rx:~$ 
 

Link to comment
Share on other sites

5 hours ago, Igor said:

Then we have a getty service running for ttyS0 and for ttyAML0 (if a serial console is operational). Then this should solve the problem

Thanks Igor, I see I have more reading to do about the available options in the build system...

Link to comment
Share on other sites

On 25/02/2018 at 9:29 AM, Igor said:


Then we have a getty service running for ttyS0 and for ttyAML0 (if a serial console is operational). Then this should solve the problem: https://github.com/armbian/build/commit/3092295cb0513ea12d40ad5aa1d988b09945ec05

 

Ok. So if this is the solution to this problem, how can I apply this in my LePotato in order to stop this loop? Remember, I am not a software developer and my knowledge of Linux is very rudimental so a need a very good description from grassrootlevel and up...

-Hans

Link to comment
Share on other sites

cd /etc/systemd/system/getty.target.wants 
rm serial-getty*ttys0

You gotta disable the service by e.g. removing the symlink like shown above. Don't remember the exact name of the symlink in getty.target.wants, so if the rm doesn't work, find out and use the correct name ;). For me disabling the service like that works (you can also try with systemctl disable), but don't blame me, if it doesn't work for you...

Link to comment
Share on other sites

On 5/19/2018 at 5:19 PM, bastiand said:

cd /etc/systemd/system/getty.target.wants 
rm serial-getty*ttys0

... don't blame me, if it doesn't work for you...

For anyone coming across this: Removing the symlink didn't work for me on Espressobin, but the following did:

systemctl stop serial-getty@ttyS0.service

 

Link to comment
Share on other sites

Hi!

 

I see these kind of messages every 10 seconds on my Odroid C2 with Kernel 4.18.8-odroidc2.

 

Nov 11 20:39:13 lx0002 systemd[1]: serial-getty@ttyS0.service: Service hold-off time over, scheduling restart.
Nov 11 20:39:13 lx0002 systemd[1]: Stopped Serial Getty on ttyS0.
Nov 11 20:39:13 lx0002 systemd[1]: Started Serial Getty on ttyS0.

 

If I try to stop it with sysctl .... , it does not work - the messages are still present in log.

 

 

 

Link to comment
Share on other sites

On 11/11/2018 at 9:39 PM, TonyMac32 said:

The C2 was using a different recipe for a while that might still have ttyS0 hiding in it, I have a few irons on the fire at the moment, I'll take a look if I get a moment

 

 

I renamed the link and rebooted, works fine for my odroidc2; no more spam in the journal.
 

# cd /etc/systemd/system/getty.target.wants && mv serial-getty@ttyS0.service serial-getty@ttyAML0.service
# ls -l
[...]

lrwxrwxrwx  1 root root   34 Sep 18 11:24 getty@tty1.service -> /lib/systemd/system/getty@.service
lrwxrwxrwx  1 root root   41 Sep 18 16:38 serial-getty@ttyAML0.service -> /lib/systemd/system/serial-getty@.service

 

Link to comment
Share on other sites

Hi,

 

I've been trying to figure out why my logging was so active and just found this thread so thank you. Not hard to spot the issue but nice to find a solution detailed for me :) 

Just an extra note on this, the getty ttyS0 spam appears to be triplicated, in /var/log/auth.log, daemon.log and syslog so fixing it removes tons of log spam from all three files.

 

All I need to do now (another issue entirely and not trying to hijack this thread) is fix SNMPD's ridiculous logging which appears to ignore any settings except via directly editing the snmpd.service file :( )

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines