Date: Fri, 12 Jan 2024 10:34:11 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: <A1F3092A-CEB1-44DE-ADB3-F45113004B34@yahoo.com> In-Reply-To: <ZaFoY58MqBv9hX5b@www.zefox.net> References: <ZZ3NGeOtadKMHgIj@www.zefox.net> <3012A549-9482-4D69-9DF4-7987E650DFFA@yahoo.com> <ZZ7fBDxYd8Yyw5fm@www.zefox.net> <E769A770-8D23-4EFC-8E75-F0ACF6705C4E@yahoo.com> <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> <ZZ8ugUkEDXbSUjZp@www.zefox.net> <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> <ZaBLnwaHWYedwY9m@www.zefox.net> <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> <8B4C76B2-707E-4978-9CB3-5D547303A7E5@yahoo.com> <ZaFoY58MqBv9hX5b@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 12, 2024, at 08:27, bob prohaska <fbsd@www.zefox.net> wrote:
> On Thu, Jan 11, 2024 at 02:51:47PM -0800, Mark Millard wrote:
>>>>>=20
>>>>> But there is no information here about which of those was the
>>>>> one to start the failure on nemesis.zefox.com :
>>>>>=20
>>>>> A) Was it the tip process?
>>>>> B) Was it the shell process?
>>>>> C) Was it the nemesis.zefox.com side of the ssh?
>=20
> It turns out that killing tip (using killall on the
> terminal server) does not disturb the ssh session.
DESCRIPTION
The killall utility kills processes selected by name, as opposed to =
the
selection by PID as done by kill(1). By default, it will send a =
TERM
signal to all processes with a real UID identical to the caller of
killall that match the name procname. The super-user is allowed to =
kill
any process.
. . .
-SIGNAL Send a different signal instead of the default TERM. =
The
signal may be specified either as a name (with or =
without
a leading =E2=80=9CSIG=E2=80=9D), or numerically.
Which SIGNAL values did you try? Did you try -SIGHUP ? There are
a bunch of signals that terminate the process(es) involved. The
handling of each can be distinct: separate signal handlers are
possible.
=46rom man signal:
Num Name Default Action Description
1 SIGHUP terminate process terminal line hangup
2 SIGINT terminate process interrupt program
. . .
9 SIGKILL terminate process kill program
. . .
13 SIGPIPE terminate process write on a pipe with no
reader
14 SIGALRM terminate process real-time timer expired
15 SIGTERM terminate process software termination =
signal
. . .
24 SIGXCPU terminate process cpu time limit exceeded =
(see
setrlimit(2))
25 SIGXFSZ terminate process file size limit =
exceeded (see
setrlimit(2))
26 SIGVTALRM terminate process virtual time alarm (see
setitimer(2))
27 SIGPROF terminate process profiling timer alarm =
(see
setitimer(2))
. . .
30 SIGUSR1 terminate process User defined signal 1
31 SIGUSR2 terminate process User defined signal 2
32 SIGTHR terminate process thread interrupt
33 SIGLIBRT terminate process real-time library =
interrupt
If you did not specify the signal explicitly, you tried:
15 SIGTERM terminate process software termination =
signal
(I'm not claiming all those "terminate process" signals are
likely to be involved. But SIGTERM is need not be involved
at all.)
> Both the ssh connection from workstation to terminal
> server and the su to root needed to run tip survive.
>=20
> I should apologize for not testing this sooner, it
> was a very easy experiment. If you think of useful
> variations please indicate them.
See above, in particular SIGHUP .
> The "invalid characters in banner" message still
> intrigue me. Might it be possible for output from
> tip to ssh inadvertently contain a ~. sequence in a
> direction that makes ssh or sshd disconnect?
I doubt ssh can be confused about where characters
are coming from.
> It does appear that what looks like console-to-terminal-server=20
> traffic is sometimes reflected back to the console as input,=20
> but only when tip is being started and not every time at that. =20
>=20
> Some help from the comp.sys.raspberry-pi newsgroup
> suggested trying
> journalctl -u ssh
> on the RPiOS workstation. It reports ssh server activity,
> essentially sshd startups at boot, but not client activity.=20
> I'll keep looking.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A1F3092A-CEB1-44DE-ADB3-F45113004B34>