0

With random occurence for ssh logins into remote terminal ('agetty') there is immediate output of unrelated characters into that ssh session terminal.
With periodical repetition these are "hh��cahh�" or "hh��!ca[" and "CR" "LF".

Furthermore copy&paste for some characters (recognized til now for: $ ") was not possible, since there was no output into terminal after (and including) these characters.

There has been no change of system configuration files since recognizing the difficulties for this Debian distribution. Some of this irregular output problems can be solved (for minutes endurance) with 

stty sane

How to debug the reason for this encoding(?) problems and how getting a process description or program name of a pid ( strace -fe write $(lsof -t "/proc/$$/fd/1" | sed 's/^/-p/' -> with separate ps | grep $pid process/program already closed ) of the process that causes this output to stdout?

ks1322
  • 1,646
  • 15
  • 26
beyondtime
  • 111
  • 6
  • `�` is typically a sign of a non-unicode characters received on a Unicode terminal. But in the context, it seems simply binary bytes sent randomly (I don’t know why). The kernel doesn’t deal with Unicode vs. 8-bits characters. No need to use `stty`. Your program should work with the correct encoding which should be given by the `LANG` environment variable. Finding the source of the bogus chars may be difficult. – Frédéric Loyer Oct 10 '21 at 18:22
  • I had this happen to me once because the `screen` configuration in the client had somehow messed up the TERM variable. Those strange sequences are terminal control characters. Check out the values of the TERM and LANG variables on the *client* before connecting (and on the server just to be sure). – LSerni Oct 10 '21 at 18:30

1 Answers1

1

With synchronizing time base between host and client side and watching the output for some time, a pattern for repeating tty output on defined periods pointed to cron services with increased probability.

Then after redirecting that binary's output (stdout, stderr) to /dev/null instead into a local logging file, this encoding disturbance to tty disappeared (with service cron reload, service cron restart).
While there's still no explanation, why encoding for the terminal session became unusable (with used typing interaction), following changes resolved encoding problem:

cron config file (encoding problem within tty):
*29 * * * * /path_to_executable/binary > /shared_memory_tmpfs/log.file

  1. printf("logging output to stdout");
  2. delete log.file if this is a multiple instance of this binary

cron config file (problem solved):
*29 * * * * /path_to_executable/binary > /dev/null 2>&1

  1. fprintf("logging output to log.file");
  2. delete, reopen log.file before this multiplied binary instance will log content into

The difficulty was to identify the origin of this tty output, because that redirected output was cleared within every recursion of every process restarted and only the short period on start caused a few characters scrambling all other following tty output (especially formatting of line forward and cursor visibility, independent from login event).
Once the cause for that had been identified, it was not difficult to resolve the problem. Anyhow, an explanation for the reasons behind would be of interest.

beyondtime
  • 111
  • 6