Re: USB-serial adapter suggestions needed

On Jan 12, 2024, at 13:45, Mark Millard <marklmi@yahoo.com> wrote:

> On Jan 12, 2024, at 13:37, bob prohaska <fbsd@www.zefox.net> wrote:
>> 
>> On Fri, Jan 12, 2024 at 12:38:30PM -0800, Mark Millard wrote:
>>> On Jan 12, 2024, at 11:18, bob prohaska <fbsd@www.zefox.net> wrote:
>>> 
>>>> On Fri, Jan 12, 2024 at 10:34:11AM -0800, Mark Millard wrote:
>>>>> 
>>>>> 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.
>>>>>> 
>>>>>> 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 .
>>>>> 
>>>> 
>>>> Just tried SIGHUP several times. The ssh connection didn't
>>>> disconnect. There were also no reports about overriding stale
>>>> locks. 
>>>> 
>>>> Using SIGKILL reported:
>>>> 
>>>> login: Killed
>>>>           root@nemesis:/home/bob # 
>>>> root@nemesis:/home/bob # tip ucom
>>>> Stale lock on cuaU0 PID=45604... overriding.
>>>> connected
>>>> 
>>>> 
>>>> FreeBSD/arm (ns2.zefox.net) (ttyu0)
>>>> but the ssh session and su survived.
>>>> 
>>>> Finally, I tried SIGSTOP. Again, ssh and su stayed up, but
>>>> restarting tip reported:
>>>> all ports busy
>>>> Power-cycling the usb-serial adpter with usbconfig
>>>> isn't able to free the port. That's new-to-me behavior.
>>>> Deleting the /dev/cuaU0-related files didn't help.
>>>> 
>>>> Not sure what to make of this, except that ssh survives
>>>> exit of tip, graceful or not.  
>>> 
>>> Remember:
>>> 
>>> Jan 10 14:29:48 nemesis kernel: ucom_close: tp=0xffffa00001979800
>>> Jan 10 14:29:48 nemesis kernel: ucom_shutdown: 
>>> Jan 10 14:29:48 nemesis kernel: ucom_dtr: onoff = 0
>>> Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=0x00, off=0x01
>>> Jan 10 14:29:48 nemesis kernel: ucom_rts: onoff = 1
>>> Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=0x02, off=0x00
>>> Jan 10 14:29:48 nemesis kernel: ucom_cfg_close: 
>>> Jan 10 15:04:07 nemesis su[35181]: bob to root on /dev/pts/4
>>> 
>>> (and what was somewhat before and somewhat after)?
>>> 
>>> What were those messages like (if any) for each of the types of kills?
>> 
>> Far as I can tell they're the same following ucom_shutdown. 
>> Preceeding ucom_shutdown it looks like the sequence of messages
>> varies a little, but obvious things like the big hex numbers
>> are clearly indentical. 
>> 
>> If you've got something in mind please tell me what it is and I'll 
>> be able to look more intelligently.
> . . .
> 

Going in a different direction of kill signal testing . . .

Showing what ssh running shells looks like, with a
little context as well:

# ps -xd
. . .
1527  -  Is       0:00.01 |-- nfsd: master (nfsd)
1529  -  S        0:00.15 | `-- nfsd: server (nfsd)
1546  -  Is       0:00.00 |-- sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups (sshd)
1628  -  Ss       0:00.10 | |-- sshd: root@pts/1 (sshd)
1642  1  Ss       0:00.04 | | `-- -sh (sh)
9531  1  R+       0:00.00 | |   `-- ps -xd
7512  -  Is       0:00.02 | `-- sshd: root@pts/0 (sshd)
7515  0  Is+      0:00.01 |   `-- -sh (sh)
1560  -  Is       0:00.69 |-- /usr/sbin/cron -s
. . .

In that, the:

9531  1  R+       0:00.00 | |   `-- ps -xd

is like where a tip command would show up as I understand. Also,
you indicated tcsh use instead of sh use. And you are not likely
using root@ as your context.

You have tried killing tip.

You could try killing the parent tcsh for the tip the various
ways instead. Same sort of results information for each signal
type. Be careful to do the kill from a distinct ssh session.

One more level of parent process could be of interest:
the equivalent of my "sshd: root@pts/" that indirectly
contains your tip command in your context. Be careful to do
the kill from a distinct ssh session. -SIGPIPE might be a
relevant test here.

Do not testing killing "sshd: /usr/sbin/sshd . . .".


===
Mark Millard
marklmi at yahoo.com