user-mode-linux-user

[uml-user] Problems reconnecting to serial line

[Paul W. <pd...@ex...>]

I'm trying to set up a UML server that will put its initial init output
on a serial line, connected to a pts on the host, and then run a getty
on this from init.

The problem I have is that I can connect to the serial line only once.
Once I disconnect from the pts, the pts is closed and I can't reconnect.

This seems to be a side effect of having init put its initial output on
this serial line.  If I don't specify CONSOLE=/dev/ttyS0 on the command
line, it all works fine (except that I don't get the initial init
output).

This seems to be the same problem as:

http://marc.theaimsgroup.com/?l=user-mode-linux-user&m=106834287519030&w=2

Is there any workaround for what I'm trying to do?  

Paul

Re: [uml-user] Problems reconnecting to serial line

[Paul W. <pd...@ex...>]

Apologies for following-up to myself, but I'm still struggling with this
one.

On Sat, Feb 21, 2004 at 02:25:01AM +0000, Paul Warren wrote:
> I'm trying to set up a UML server that will put its initial init output
> on a serial line, connected to a pts on the host, and then run a getty
> on this from init.
> 
> The problem I have is that I can connect to the serial line only once.
> Once I disconnect from the pts, the pts is closed and I can't reconnect.
> 
> This seems to be a side effect of having init put its initial output on
> this serial line.  If I don't specify CONSOLE=/dev/ttyS0 on the command
> line, it all works fine (except that I don't get the initial init
> output).

How hard would it be to make it so that it never hangs up the TTY inside
the UML machine?  From my point of view, it would be perfectly
acceptable, possibly even desirable, that a session inside the machine
remains open through multiple connections to the pts. 

I've had a bit of a meddle myself, but my amateur attempts at hacking
this in have been somewhat unsuccessful.  I'm happy to continue trying,
but I'd be very grateful for some pointers.

thanks,

Paul

> 
> This seems to be the same problem as:
> 
> http://marc.theaimsgroup.com/?l=user-mode-linux-user&m=106834287519030&w=2
> 
> Is there any workaround for what I'm trying to do?  
> 
> Paul
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> User-mode-linux-user mailing list
> Use...@li...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user

Re: [uml-user] Problems reconnecting to serial line

[Jeff D. <jd...@ad...>]

pd...@ex... said:
> How hard would it be to make it so that it never hangs up the TTY
> inside the UML machine?  From my point of view, it would be perfectly
> acceptable, possibly even desirable, that a session inside the machine
> remains open through multiple connections to the pts.  

That's not how terminals work.  When one is detached, the session on it dies.

If you don't want that, what's wrong with putting the session inside a screen
and detaching that?

				Jeff

Re: [uml-user] Problems reconnecting to serial line

[Paul W. <pd...@ex...>]

On Mon, Mar 01, 2004 at 08:37:06PM -0500, Jeff Dike wrote:
> pd...@ex... said:
> > How hard would it be to make it so that it never hangs up the TTY
> > inside the UML machine?  From my point of view, it would be perfectly
> > acceptable, possibly even desirable, that a session inside the machine
> > remains open through multiple connections to the pts.  
> 
> That's not how terminals work.  When one is detached, the session on
> it dies.

That depends.  If I'm using minicom to access a console on the serial
port it depends on whether I tell minicom to hangup when I disconnect (I
don't usually).  This is not my real concern - I'm not too fussed about
whether the session dies or not.  My real concern is whether I can
connect to it afterwards (new session or otherwise).  If I put the
initial console on the serial port, I can't reconnect to that console
after a disconnect.

> If you don't want that, what's wrong with putting the session inside a screen
> and detaching that?

That works for me, but not for users.  I need to make the system
fool-proof so that users can't lose the ability to connect to their
machine just because they hit the wrong button when leaving screen.
Also, I use a rather more stripped down terminal emulator as I don't
wish to make screen available to users.

Paul

Re: [uml-user] Problems reconnecting to serial line

[Dan L. <ar...@co...>]

Paul Warren wrote:

>>If you don't want that, what's wrong with putting the session inside a screen
>>and detaching that?
>>    
>>
>
>That works for me, but not for users.  I need to make the system
>fool-proof so that users can't lose the ability to connect to their
>machine just because they hit the wrong button when leaving screen.
>Also, I use a rather more stripped down terminal emulator as I don't
>wish to make screen available to users.
>
>Paul
>
>  
>

You can just disconnect the tty from screen and it'll still be up.  
About the only thing you can't do is do a "kill -9 `pidof screen`" :)

I use screen for all of my UML sessions, and it's really idiotproof.  
That's an important feature for me, considering I'm using it.
But, if you don't want screen available to the users, you can run screen 
as another uid, and make the serials available.
--Dan

-----------
This email message and any attachment may contain Confidential or
Protected Health Information. If you are not the intended recipient
please notify us immediately at 480-648-4545 and delete the message.

Re: [uml-user] Problems reconnecting to serial line

[Paul W. <pd...@ex...>]

On Tue, Mar 02, 2004 at 07:53:06AM -0700, Dan Lund wrote:
> >That works for me, but not for users.  I need to make the system
> >fool-proof so that users can't lose the ability to connect to their
> >machine just because they hit the wrong button when leaving screen.
> >Also, I use a rather more stripped down terminal emulator as I don't
> >wish to make screen available to users.
> 
> You can just disconnect the tty from screen and it'll still be up.  
> About the only thing you can't do is do a "kill -9 `pidof screen`" :)

You can detach (Ctrl-A D) but you can't quit (Ctrl-A \ or Ctrl-A Q or
whatever it is), as this causes the TTY to hang up, and if you used that
TTY for output from init during boot, it won't respawn.

Do you see different behaviour when you quit screen?

> I use screen for all of my UML sessions, and it's really idiotproof.  
> That's an important feature for me, considering I'm using it.
> But, if you don't want screen available to the users, you can run screen 
> as another uid, and make the serials available.

I don't understand what you're suggesting here.

Paul

Re: [uml-user] Problems reconnecting to serial line

[Dan L. <ar...@co...>]

Paul Warren wrote:

>You can detach (Ctrl-A D) but you can't quit (Ctrl-A \ or Ctrl-A Q or
>whatever it is), as this causes the TTY to hang up, and if you used that
>TTY for output from init during boot, it won't respawn.
>
>Do you see different behaviour when you quit screen?
>
>  
>
When I quit screen, I don't really "quit". I just detach from it. I 
usually either do a ctrl-a d as you said, or I just close the xterm 
because I'm almost always in XWindow. Screen does have the ability to 
alter keys, so you can turn that feature off. I use screen as an 
ameteur, so basically it's features are completely unused by me other 
than detaching and naming. I do know that the ctrl features are 
alterable with screen, though.

>>I use screen for all of my UML sessions, and it's really idiotproof.  
>>That's an important feature for me, considering I'm using it.
>>But, if you don't want screen available to the users, you can run screen 
>>as another uid, and make the serials available.
>>    
>>
>
>I don't understand what you're suggesting here.
>
>  
>
Having a primary console via screen is all well and good, but having a 
serial console is probably the better way to go for less vulnerability 
when it comes to what a user does. (such as quitting screen, as you said 
above) That's what I'm suggesting. Perhaps having a a serial console 
available for the user, instead of giving them direct access to the 
primary "screen" session.

-Dan

-----------
This email message and any attachment may contain Confidential or
Protected Health Information. If you are not the intended recipient
please notify us immediately at 480-648-4545 and delete the message.

Re: [uml-user] Problems reconnecting to serial line

[Paul W. <pd...@ex...>]

On Tue, Mar 02, 2004 at 10:22:10AM -0700, Dan Lund wrote:
> 
> >You can detach (Ctrl-A D) but you can't quit (Ctrl-A \ or Ctrl-A Q or
> >whatever it is), as this causes the TTY to hang up, and if you used that
> >TTY for output from init during boot, it won't respawn.
> >
> >Do you see different behaviour when you quit screen?
> >
> When I quit screen, I don't really "quit". I just detach from it. I 
> usually either do a ctrl-a d as you said, or I just close the xterm 
> because I'm almost always in XWindow. Screen does have the ability to 
> alter keys, so you can turn that feature off. I use screen as an 
> ameteur, so basically it's features are completely unused by me other 
> than detaching and naming. I do know that the ctrl features are 
> alterable with screen, though.

Yeah, but I'd rather not use screen at all for security reasons.  I'd
rather work on a patch to UML for what I see as a bug, than work on a
patch to screen to remove features.

> >>I use screen for all of my UML sessions, and it's really idiotproof.  
> >>That's an important feature for me, considering I'm using it.
> >>But, if you don't want screen available to the users, you can run screen 
> >>as another uid, and make the serials available.
> >
> >I don't understand what you're suggesting here.
> >
> Having a primary console via screen is all well and good, but having a 
> serial console is probably the better way to go for less vulnerability 
> when it comes to what a user does. (such as quitting screen, as you said 
> above) That's what I'm suggesting. 

I don't understand the distinction you make between a serial console and
a primary console.  I want the users to be able to access the console at
boot time.  I guess this makes it a primary console.  However I'm
currently doing this by setting up the UML with a console on a serial
port, attached to a pts in the host.

> Perhaps having a a serial console 
> available for the user, instead of giving them direct access to the 
> primary "screen" session.

Unforunately the whole aim is to give them access to the primary (boot
time) console.   Otherwise, I wouldn't have a problem.

I've have already spent a few hours working on a patch, but I'm totally
unfamiliar with either the UML or kernel codebases, so doing so is like
wading through treacle and I've made very little progress. 

I'd be very grateful for any pointers on how this stuff works, and what
I should be looking to do to prevent a tty hangup and to respawn the pts
after it is closed. 

cheers,

Paul