You are not logged in.
I've got an app (UT server) that I wanted to run as a non-root system user. At the same time, I didn't particularly want said non-root user to start the app themselves. The reasoning is silly, and not pertinent to my main question, which is posed later on.
Anyway, I start up Putty, log in as "xtrj7", then su to root, and use the following command to start the server:
/bin/su - xtrj7 -c "cd /storage/UT/ut2k4/System
&& /storage/UT/ut2k4/System/ucc-bin server
CTF-BridgeOfFate?game=xGame.xCTFGame
ini=UT2004.ini -nohomedir > /dev/null &"
I purposefully broke it into multiple lines for readability, but when entered, it's on one line.
I used the "> /dev/null &" at the tail in order to supress the on-screen logging and background the process. Why? Because I've read enough guides on the net about backgrounding processes to be dangerous Seriously, the recommendation to background the server on a linux box when accessing via Putty is contained in a tutorial on unrealadmin.org.
This command will start the UT server, so that bit works. I type "exit" at the root prompt, and there's no problem there. One more exit to log out of my normal user account ("xtrj7", the same account as in the code above) and Putty, and it hangs indefinitely.
Can anyone point me in the right direction? I am a bash scripting noob, zero experience. This is my first attempt to use a relatively complicated (for me!) command. Any feedback will be most appreciated.
Thanks,
Andrew
Offline
use screen, and run your process in that. You can detach the screen instance, and it will stay running after you logout from the box.
And, I would probably use sudo to run an app as another user, instead of su..But then again, I would probably run it as the user, instead of su'ing to the account and running it from there. *srug* but that is just me..
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
Excellent advice, and your methods will definitely work. I appreciate the suggestions.
For my own knowledge, it would be interesting to hear why this particular combination of putty and su command is causing the hangup during logout.
Offline
dont use putty? try using regular ssh
Offline
dont use putty? try using regular ssh
putty is the de facto windows ssh... unless you can grab something like cygwin or windows ports of the gnu utils...
Offline
Excellent advice, and your methods will definitely work. I appreciate the suggestions.
For my own knowledge, it would be interesting to hear why this particular combination of putty and su command is causing the hangup during logout.
Maybe because there is still a process backgrounded, and logging out with a backgrounded process in most shells exits the process, and may send additional traffic for the closedown portion of the termination of putty (unclean exit/termination). This might cause putty to appear to hang, when in fact, this is the default behavior for putty. Another reason to use screen. It detaches so it is not "backgrounded" in the classical bash job management sense. think of it running in daemon mode.
putty by default stays open after a terminal has closed impropely (with an error). You can force it to close after you terminate your session (regardless of errors), like you would expect it to..
Under the session properties, at the bottom, set "close window on exit" to "always".
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
cactus,
Thank you for the great info. Your description led me directly to Linux: Rute User's Tutorial and Exposition. Section 20.7.11 covers persistent background processes, and how to prevent a logout from the shell taking child processes with it (called "forking twice, and redirecting the terminal to dev null").
The author used rxvt as an example:
{ rxvt >/dev/null 2>&1 </dev/null & } &
I simply adapted the code to my process:
/bin/su - xtrj7 -c "cd /storage/UT/ut2k4/System &&
{ /storage/UT/ut2k4/System/ucc-bin server
CTF-BridgeOfFate?game=xGame.xCTFGame
ini=UT2004.ini -nohomedir >/dev/null 2>&1 </dev/null & } &"
Now Putty does not hang when logging out of the normal user account. I understand enough to have a general idea of how it works, though not enough to understand the details. Time for some more reading
Much thanks for the assistance!
Offline
iphitus wrote:dont use putty? try using regular ssh
putty is the de facto windows ssh... unless you can grab something like cygwin or windows ports of the gnu utils...
Well it is a linux forum, and theres a linux version of putty, so i just assumed thats what he was using...
Offline
and theres a linux version of putty
really? heh, didn't know that... I only know putty from using it at work...
Offline
I hope the UT server drops it privileges and switches to another user after startup...
Offline
Sorry about the putty confusion. I should have made it clear I am accessing a linux server box from a Windows XP machine over the LAN using Putty.
I hope the UT server drops it privileges and switches to another user after startup...
I was using the "su <user>" command to make sure the server was not running as root even though it was started while logged on as root. After startup, I could see the server was, indeed, running as the specified non-root user.
Is there a way to force an application to drop privelidges and switch to another user after startup? My spidy sense is telling me the su method I've used might have some security holes.
Offline
su <user> -c <"cmd opts">
executes a command as the given user.
You can't change the userid of an already running program externally as far as I know (not easily anyway, attaching gdb and hacking away may work).
Oh wait:
Anyway, I start up Putty, log in as "xtrj7", then su to root, and use the following command to start the server:
Your code already does the above, you never su to root at all. The su'ing to xtrj7 isn't needed if you are already logged in, though it looks like a sort of hack to detach from the ssh. Though with the other trick it shouldn't be needed anymore... But all in all just using screen is much easier.
Offline