Process kill via Console

[Rajvardhan]

Dear experts,
I am in a bit of dilema here. I have an Hp integrity blade server for which root password has expired.
Also, to make matter worse the OS is not prompting me to reset the password.
From  HP forums i saw that i i can have root access via Console while connecting through ILO.
But there is another problem, In the console a process which i launched days aso is still running, and any attempt to put that process in background via CTRL+Z is unsuccessful.
Is there any way that i can kill that process or put it in background through ILO commands or MP commands without rebooting the server?
No other user account has sudo access.
Any suggestions will be helpful.

[Bill Hassell]

On the console connection, try CTRL-D. The process may be reading the keyboard and needs an end-of-file character. 
Then try CTRL-| (vertical bar). That sends a different kill signal to the active process.

And as a best practice in the future, never run general programs from the console. It should be reserved for command line only and never left running anything. Also, never use the console to telnet/ssh to another system. Activating sudo for a sysadmin login would be quite useful in the future.

[Rajvardhan]

Thanks Bill, for the reply. I really appreciate it.
I tried the combination CTRL-D and CTRL-|, but nothing happened . The process is still in the foreground.
Here is the OP of the "ps -ef | grep console" command when run by a regular user.

root 6404 1 0 Mar 16 console 0:00 -bash
raju 4943 4941 0 11:53:07 pts/5 0:00 grep console
root 5180 6404 0 Apr 25 console 0:18 find / -name login_time
 
By CTRL-|, you mean CTRL+ SHIFT + | (the vertical bar is on the same key on my keyboard just above the backslash).
Tried this as well, but it did not do anyting.
This server is 8+ yrs old. The management dont wan't to reboot the server, fearing the sever may not come up after a reboot .
Any other workaround that might help?

[Bertram Stoeckler]

You can try to enter "cntrl-Q", and then cntrl-C.

cntrl-S and cntrl-Q stop and restart the console-output. Maybe cntrl-S had been accidently entered and the process is waiting for the cntrl-Q.

cntrl-C should then be used to exit the "find".

Do you know if the "find" command that is listed in the ps-output is actually doing something? You may be able to check this with top or glance. If it is running, then it simply may need more time to finish.

There may also be an option to reset the ILO.

[Bill Hassell]

The find command is the problem.

Never use find /.

You are searching *every* moutpoint including network, CD/DVD, external mass storage...
It could take 3 days to read every possible directory.

You can fix the problem quite easily: kill 5180
(from a different window)

When you use small computers with 1 disk, it is common to "search everything".
But it is a very bad practice.
Your system may have billions of file names across dozens of terabytes of data.
I actually created an alias for find that was a script.
It tested for find / and if found, would create a message like this:

"The command find / may take several hours to complete on this server as it will search network drives, databases, even CDs. Limit the search range to reasonable locations such as /home or /usr or /tmp. You can specify several mountpoints like this: find /usr /var /tmp /home

Your find is searching for a filename with the exact string login_name which may not exist. It might be login-name or LOGIN_NAME which will won't be found. So rather than use the -name option, pipe the find results to grep for a partial match, like this:

find /usr /opt /var /tmp /home | grep -i login

I have seen these poorly formed find commands severely impact production machines with massive I/O loads, affecting dozens of users at the same time.

[Steven Schweda]

> Never use find /.

   That advice seems overly restrictive.

      find / -xdev [...]

      man find

[Bill Hassell]

...overly restrictive...

For workstation users or systems with just a couple of disks, you would be right.

But the same HP-UX runs on systems with terabytes of RAM, dozens of processors, and petabytes of  storage, an unrestricted find / will take hours and unnecessarily flush the File Cache (aka, Buffer Cache) with directory entries.  I've had many questions about performance issues where find / was the culprit. 

The point is to not look in places that don't make sense.

[Steven Schweda]

> The point is to not look in places that don't make sense.

   And _my_ point was that "-xdev" would confine the search to the "/"
file system irself.

>       man find

[Dennis Handly]

> And _my_ point was that "-xdev" would confine the search to the "/" file system itself.

Right and Bill will tell you there should be "nothing" there.  :-)

I use -xdev all the time so I don't get into the NFS mount jungle.

[Dennis Handly]

@Bill Hassell find /usr /opt /var /tmp /home | grep -i login

Instead of using grep, you should use -name, if all upper or lower case:

find /usr /opt /var /tmp /home \( -name "*login*" -o -name "*LOGIN*" \)

find /usr /opt /var /tmp /home -name "*[lL][oO][gG][iI][nN]*"