Hi,

Some of the Unix systems, such as AIX, or HPUX, are able to go back to the login prompt after entering "exit" in the shell without closing the socket, or I guess, the getty session.
Is it possible to do it in Linux? So eg, a Windows user, running a terminal emulation software does not need to "reconnect" to the host ( the software running on RHEL Linux requires user to login multiple times during the day to use different features/menus ) - reconnecting using a proprietary telnet/ssh client application is less than pleasant, and efficient.
I messed with the stty terminal options such as HUPCL, but so far I am unable to mimic this behavior on a Linux system - plus it has been quite a few years since stty was an essential tool used on a daily basis to control rs232 session behavior...

Thank you for any ideas,

Mike

You really shouldn't be using telnet these days. Use ssh as it is more secure.

You can download PuTTY for free to do ssh sessions from Windows to Linux/UNIX servers.

In PuTTY you can save sessions to use.

You can then create an icon on the desktop to automatically launch a predefined session to get the login prompt.

Say I have host name "billybob". I create and save a session to login to billybob in PuTTY. I then create an icon to run the command:
"C:\Program Files (x86)\PuTTY\putty.exe" -load "billybob"

(The path to your putty.exe might be different.)

Or from CMD window you could just run 'putty -load "atljcl06"'

There are also ways to simply login with ssh trusts bypassing the need for a login prompt at all but you'd need to consider whether you want to allow that especially if the trust is from a laptop that might fall into the wrong hands.

as above
there are still a few uses for telnet BUT not for loging in to a server
NASA/JPL/NAIF still have a telent service BUT it is for public data ( orbital data for moons,spacecraft,asteroids,...) and not for loging in

or

if you are in a lan with NO outward facing machines telnet can still be used

but ssh is preferred

despite the fact that both replies are basically off topic - thank you folks for taking the time...

I am not really asking about advantages ( if any ) and disadvantages of using telnet, but about not closing the socket or killing the getty process when executing "exit".
The terminal emulation software is not "putty", but a proprietary software used in various environments, called ViaDuct, especially in Pick and MV database environments.
It is also not about hitting the icon so the application re-starts after an exit...
If some of you have some experience with rs232 terminal servers from eg. Digi Int, Systech, etc, would exactly know how dumb terminals, or some TCP sessions behave when the system is told not to kill getty after the exit... this was done via /etc/gettydefs I believe on SCO Unix, and same/similar naming for the conf files on HPUX & AIX.
Since it has been good 10-12 years since I worked with these systems and rs232 communications, unfortunately, probably due to too many parties, drug and alcohol abuse, I am not able to recall the stty settings other than clocal and hupcl that were responsible for this desired getty behavior... this is the main reason why I stopped by this "magic" place yesterday to post my question.

again, thanks

Mike

Although you did allude to "a proprietary telnet/ssh client application" you did not actually say that was what you were using. You asked about telnet and how to make it less painful to log back in so I believe my post was on topic.

I did rs232c back in the day (on SCO UNIX, AT&T UNIX, NCR UNIX, HP-UX, SunOS [before Solaris], Solaris, Xenix, and flavors most people have never heard of such as NEC Asterix [Not the later telecom software]. However, like you I've not needed to do anything with this in years.

There IS a man page for stty in Linux. You might also look at the man pages for terminfo and termcap.

My recollection of getting a new login prompt on same serial connection though was that it was done because the /etc/inittab entry for the specific serial port had "respawn" on it which told it to restart the process (typically a gettydef) each time the program was exited. I also recall /etc/gettydefs defined the various ones to be used (e.g. 9600 although it is a baud rate was also the name of a defined gettydef). On checking just now I do see there is a man page for mgettydefs on Linux (RHEL at least).

The /etc/inittab I see on RHEL though says:
That /etc/sysconfig is a RedHat thing so may not exist in other Linux distros.

Thanks MensaWater,

I did more "thinking" about this request to prevent dropping of the connection - in rs232 world, as you know, it is done on the hardware level via DCE/DTE/DTR, and software, like you mentioned, to "respawn" via eg. getty. This restart of the process is true for serial connections ( and devices such as a graphical console )... In case of telnet or ssh, after issuing 'exit' it kills processes assigned to the specific tty/ptty device, and closes the socket - the restarting of the connection needs to be done on the client side, to "simulate" DCE/DTE or DTR, so the requirements are met to assign a new tty and start a process.
I am not sure what type of "hacks"/mods would needed to be applied to telnet or ssh to prevent the socket close, but it is nothing that I would be able to do, nor will continue researching or nor persuing.
I rather open a feature request to the developers of the terminal emulation client ( btw, I mentioned it, it is ViaDuct ), to eg, re-connect to last session after hitting a return key, like it is done in some of the telnet/ssh clients already, so the user can quickly establish the connection without messing with eg. the mouse. A background macro app that opens the terminal and reconnects to the host via a key combination would also be another "workaround", which initially I was not considering as a "solution" to closing the socket.
Sorry for my earlier comment about "off-topic", but over time I have noticed that often, when people are looking for a "solution" to a specific problem, all they get is workarounds - here is a short, recent story...
A mobile terminal/scanner manufacturer provides/supports terminal emulation software, and a deployment environment, that for some reason sends terminal type in uppercase...
Of course the system says "wtf is VT100?" - their support asks: "can you make the system accept the uppercase?" - "well, yes, but why?"..... this is when I get upset - workaround vs "solution".

have a good day! and again, thank you.

Mike

EDIT:
Btw, I started my experience with rs232 in multi-user environments on Honeywell Level6 and DEC LSI11 systems while several of the insurance, etc. businesses were still running them as a production system... this was before they migrated to (more) modern RISC and CISC systems.

If you log out of a serial connection and the server does NOT restart getty/agetty - you will not be able to login again.

A serial line is a physical connection. It isn't disconnected when you logout.

A network connection is closed when you log out... thus you have to reconnect - and that restarts the login procedure.

BTW, leaving a connection open is an invitation for a DOS attack. And even worse for an unencrypted telnet - as the session can be spied on since your passwords are not protected.