Re: USB-serial adapter suggestions needed
- Reply: Mark Millard : "Re: USB-serial adapter suggestions needed"
- In reply to: Mark Millard : "Re: USB-serial adapter suggestions needed"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 12 Jan 2024 21:37:52 UTC
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. Thanks for writing, bob prohaska