Diferences between Shutdown command issued console & telnet

[Filipe Litaiff]

Hi Forumers,

Is there any difference between a shutdown command issued in a console and issued in a telnet session? We've observed that the subsequent startup takes longer if the shutdown was issued in the console.

Moreover, this longer startup shows a misconfigured console, plenty of dots around and the rest is almost unreadable.

Any ideas, folks?

Thanks,

Filipe

[harry d brown jr]

There shouldn't be, well at least from what I have seen. The telnet session that issues a shutdown will be killed and all output from the shutdown will be reverted back to the console.

live free or die
harry

[Duncan Edmonstone]

Never heard of this before... what type of console are you using?

[Filipe Litaiff]

Duncan, It's a regular character console.

[Duncan Edmonstone]

Some things to look at:

What type of server is it? Modern HP servers (N/L/A class) need to have the console terminal mode set to vt100 for ceratin screens to display correctly during boot. Older systems should be hp2392a or 70096.
Have you tried re-setting your console to its defaults by turning off, holding down the 'd' key and turning back on while keeping the key held down?
What does the console line say in /etc/inittab ?
What are the default tty definitions for the console in /etc/gettydefs ?

As for the boot taking longer, have you timed it? How much longer is it taking? Which shutdown command are you issuing, presumably something like 'shutdown -y -r 0'. As Harry says, this is no different whether you issue it from the console or a terminal, except for where some of the output during the shutdown goes. Certainly from the point where the system is reset and the PDC code starts executing, it should be identical.

HTH

Duncan

[Uday_S_Ankolekar]

Hi,

If you give shutdown command from console you can watch, monitor shutdown /rebooting process. telnet won't give you this!
Secondly when systems comes up you can telnet to the server before you can start working on console because systems start multiuser env and netork protocols are ready to receive commands but console has to complete other system related tasks before it gives you console login

-USA..

[Roger Baptiste]

<>

None whatsoever. The command
from the telnet session will
break the telnet and continue the shutdown process. Then, you would need to move over to the console to see the shutdown process status messages.

<>

Hmnm, are you sure?? because the process is the Same! Are you bringing the system in a different INIT mode?

>

Well, the console will show you the ouput of the boot process and thats the only way you would see all the dots and characters on the screen. did you try switching the console off and on?

HTH
raj

[Anthony deRito]

If you have one of those VT100 consoles, reset to factory defaults by holding down Ctrl key and pressing the "d" key while recycling the monitor power.

[Filipe Litaiff]

Hi Guys, thanks a lot.

Yes, the boot process takes much more time when its done by the console, about 1 1/2 h longer. I know it's weird, but's true. I Think resetting the console could be a good try. It's a N4000 box, pretty robust.

[Christopher McCray_1]

Forgive me for saying and if I am assuming too much, but 1.5 hours????!!!

I have 10 N-class servers in a varety of configurations and all of them reboot in under 20 minutes. What is your configuration if I may ask because this does not sound normal at all. Have you looked at your rc.log file afterwards to see if any errors occurred?? Also, as for your terninal output, it depends on the actual console type which determines the terminal type you choose. On some I have it set to hp, on others vt100 (hp works in all cases I believe). Please let me know what you find on my first response. Thanks and good luck.

Chris

[Duncan Edmonstone]

Wow! an hour and a half! - What part of the boot sequence seems to take much longer:

1. VFP (Virtual Front Panel -all the hex codes)
2. ISL (the bit where you can interrupt)
3. HPUX (the bit where you see ..../stand/vmunix and then a message about relocating PDC)
4. rc (the bit with all the OK|N/A|SKIP|FAIL messages)

If its the last bit, it could be it is getting far enough thro the rc scripts for networking to be started and you think the boix is up, but inreality its still booting... do you have some bespoke applications with long start times? (e.g. I've seen people write startup scripts for Oracle applications which pins lots of packages into the SGA - thi scan take 20 minutes alone to run if there's a lot of packages)

HTH

Duncan

[H.Merijn Brand (procura]

This all seems very related to what I observe on my 11.00 systems (L1000, A500, rp2470)

--8<--- /etc/rc.config.d/list_mode
TERM=hp
LIST_MODE=1
LIST_TIMEOUT=0
USE_COLOR=0
-->8---

I don't want the curses-like output, but a straight (fast) list. Only the fast turns out to be slow, because the rc process uses 999 char wide lines instead of 78-80 columns. I guess this is what Filipe meant in his thread.

adding

COLUMNS=80

in /etc/rc.config.d/list_mode does not help, and neither does adding 'export COLUMNS=80' in /etc/rc.config.

Of course I can change MAX_COL=80 in /sbin/rc.utils, but that's likely to be overwritten on system updates and it does not help either, nor does it sounds like a good spot to limit these kind of things. IMHO, HP should rewrite these utils to allow limits to be passed from non-auto overwritable files from /etc/rc.config.d

What is the `officially' designated spot to limit the screen width to 80 characters in list_mode 1?

FWIW IMHO using 999 as default in list_mode 1 is an unreasonable choice of HP!

And for those who do not want for HP to fix it, attached limits the width to a default (ASCII) screen :)

Enjoy, have FUN! H.Merijn

[Bill Hassell]

The console problem is almost always related to the terminal type. In the current GUI-crazed world, anything without a mouse is called a 'dumb' terminal and that is far from an accurate description of character mode terminals, especially HP terminals and emulators. To make things a lot worse, the N,L and A-class computers (and the newer rp-series) have a separate computer called the GSP and due to changes made in the terminal ID programs (ttytype and tset), the 'real' terminal on a console port is no longer automatically identified.

Let's start with 80 columns. This is an industry standard for character terminals and for truly dumb terminals like the vt100, cannot be changed. An HP terminal (such as the 700/9x series) can indeed be changed as well as true HP terminal emulators such as Reflection for HP. Making the COLUMNS value wider than the 'real' terminal will make a mess out of screen-oriented programs such as vi. Setting COLUMNS=999 doesn't make any sense since even if you could make the screen display 1000 characters per line, you couldn't read the small characters. This sounds like a hack to eliminate line wrap for some batch program or perhaps a central terminal logging program.

As far as delays in start/stop, you'll need to identify where the delays occur. A 90minute reboot sounds very strange, but is most likely related to just a couple of non-HP-UX start scripts.

Finally, the terminal on the console MUST match the GSP override. The default for the GSP is vt100, regardless of what you have connected to the console port. If you have an HP terminal or HP terminal emulator, the override will indeed mess up your screen. The solution is to use CTRL-B to enter the GSP interface and then type CA for configure the console port. Change emulation from vt100 to hpterm, exit from the GSP and login again. With a true HP terminal, SAM (and swistall and vi, etc) all work as expected.

[RolandH]

Hey Filipe,

that sounds your server is an older one like K-Class. The older server checks at boot time if a console is connectet. So I think you have to check if the console is connected right. Is this server far away from you? You can try to connect a web console instead of a character console. A web console is working for all server, where you can connect a character console (HP7xx). A reset of the console is a god idea. Sometimes the boot hangs if the check on the console fails. I have had this problem with a K-Class server. I have switched off the console, because I want save energy. But then I was constrained to reboot the server and the boot stops at the console check. The solution was to switch on the console, reset the console and the restart the server. Then everything was fine.
Another tip. If you want see the shutdown process of you server with telnet session, then switch first in singel-user mode (init s)

from init manpape
" S|s Enter the single-user environment. When this level change occurs, the logical system console /dev/syscon is changed to the terminal from which the command was executed. "


Kind Regards
Roland

[H.Merijn Brand (procura]

Bzzzzzt, guys, look at the date of the question. Bill added extra info, just like me. I was looking for a better answer than my workaround, but since this thread was closest using forum find, I added my workaround here.

I bet Filipe is not interested in the answer anymore :)

Bill, I agree, but I realy don't care what type of terminal my console is *during boot*. A vt52 or paper terminal would do. Maybe that is why I choose list_mode 1: fast and simple. But rc.utils makes it unreadable and slow. That's what my patch `solves'.

Indeed the boot time is cut in half!

Enjoy, have FUN! H.Merijn