Running Unix Command without attaching to TTY

[Shivkumar]

Hello,

We observed PowerBroker running some unix privileged commands attached to a TTY device. When it times out due to some inactivity then it dies and eventually kills other applications supposed to run with PowerBroker privileged access.

I was thinking to execute the command like "$./nohup " so that it does not attach with a TTY device.

My question is:
Does nohup works with any unix command or is there any exception ?

Thanks,
Shiv

[Mark McDonald_2]

Hi Shiv

I am not aware of any commands that cannot be used with nuhup.

Don't forget to monitor the size of nohup.out, and also use a '&' if you want the command in the background.

Mark

[Steven E. Protter]

Shalom,

I believe it works with all commands except those that require keyed input.

Works with nearly every script I ever wrote except that type.

SEP

[James R. Ferguson]

Hi Shiv:

Yes, 'nohup' should work with any command (or script). Redirect STDOUT and STDERR to a file of your choice. Otherwise, output will be sent to 'nohup.out'. When run with 'nohup' the hang-up (SIGHUP) and quit (SIGQUIT) signals are ignored.

Regards!

...JRF...

[James R. Ferguson · Accepted solution]

Hi (again):

> SEP:
I believe it works with all commands except those that require keyed input.

You can redirect STDIN to accomodate this:

# nohup mything > /tmp/mything.log 2>&1 < /dev/null

...or if you need specific input responses, put them on separate lines in a file and redirect that in lieu of '/dev/null'.

Regards!

...JRF...

[George Spencer_4]

If the nohup does not work, then another option is to run the program using the "expect" programming language.

We have an application which is started when remote hardware makes a connection to a specific port. The developer's application would not run directly from inetd, we tried it, but would exit with an error message stating that it required a tty. The developer's solution was to used rlogin to provide the tty. This worked, but we were not happy with the use of rlogin. We have since replaced the developer's script with a simple "expect" script. The expect programming language provides the tty, and we are now able to disable rlogin in inetd.conf.

[Shivkumar]

Does it mean that if a process or program started by inetd daemon then it will not attach to TTY ?

[Laurent Menase]

yes, it will not be attached to a tty.


it is not advised to detached with nohup
process like vi, more, which open /dev/tty.

else there is no other problem

if you need to have a tty, you can use
rlogin, ssh, or redirect stdin to /dev/console for instance.

rlogind and sshd and telnetd open a master pty and a slave pty which is passed to its child process.

[Srimalik]

I am not very sure about the requirements here.
But I regularly use screen to keep my session alive after I have disconnected from the machine.

You can also start your process in a screen session and detach. You can have any kind of(text only) application running under screen no need to worry about the keyboard input and output.

[Shivkumar]

Malik,

Could you please elaborate ?

[Srimalik]

Screen a terminal multiplexer and in addition to many other functions it can also solve your problem.
http://en.wikipedia.org/wiki/GNU_Screen
http://www.gnu.org/software/screen/

[Shivkumar]

Also i think if a process runs as a daemon process then it does not attach to TTY... is this correct statement ?

[James R. Ferguson]

Hi Shiv:

> Also i think if a process runs as a daemon process then it does not attach to TTY... is this correct statement ?

A daemon begins life when its parent process fork()'s and exit()'s. The new process then _detaches_ itself from its controlling terminal (TTY) as a part of becoming a daemon. This is done via a 'setsid()' system call. Doing this prevents the daemon from receiving any signals from the terminal that it was once (by inheritence) connected to.

Too, STDIN, STDOUT and STDERR which are usually associated with a terminal, are either cloasd or opened to '/dev/null' or a file as necessary. You _could_ (for example) open STDOUT to a terminal and let your daemon process write to it, but then why have a daemon(?).

Regards!

...JRF...