Using the nohup command !

[Ivan Azuara]

Hi!

I have a strange behavior with a script that has defined the nohup command in his content.

The problem is when i execute this script through the crontab scheduler, because this doesn't leaves running the executable program. But if I execute this script since the unix prompt the script run succesfully.

NOTE: The name of the executable program is Interprete.

The line of the nohup command is

nohup Interprete &

The porpuose of this script is when a backup process finished, the crontab scheduler launch this script leaving the Interprete program running on the system like a daemon.

In other times when i execute the nohup line since the crontab scheduler, the nohup.out file doesn´t increase his size like the Interprete program doesn´t works.

30 23 * * * /usr/bin/nohup /switch/Interprete & > /switch/nohup.out

The nohup.out is used like a log file for the behavior of the Interprete program.

Some idea ?

[Ivan Ferreira]

I'm wondering why run a daemon like script from crontab, why don't you start right after the backup process from the backup script itself? Would you have multiples intances of the interprete script after a couple of days (if it runs).

[A. Clay Stephenson]

A good point is why try to run a daemon as a cron script. Evenso, it is not sufficient to simply nohup a command in the backgroup and call it a daemon. Properly daemonizing a process requies that no long does it ignore some critical signals (and nohup over covers some of those) but also that the process be the leader of a new session so the system call setsid() must be used. This just isn't done correctly in the shell.

The attached Perl script will do the job for you and because it fork()'s and exec()'s there is no need to start it in the background --- another characteristic of a proper daemon.

[A. Clay Stephenson]

A good point is why try to run a daemon as a cron script. Evenso, it is not sufficient to simply nohup a command in the backgroup and call it a daemon. Properly daemonizing a process requies that no long does it ignore some critical signals (and nohup over covers some of those) but also that the process be the leader of a new session so the system call setsid() must be used. This just isn't done correctly in the shell.

The attached Perl script will do the job for you and because it fork()'s and exec()'s there is no need to start it in the background --- another characteristic of a proper daemon.

[A. Clay Stephenson]

Ooops, the response was slow and I hit submit too quickly. I should add that if you
want to daemonize another process then change the line in daemon.pl that contains the exec() function. I could have made a fancier version that actually parsed the command line for the command to exec but I already have a script that was close --- and besides, the fancy additions such as passing the command and it's arguments and any possibly needed environment variables needed by the exec()'ed command is left as an exercise.

[Raj D.]

Ivan ,

If you want to run through cron , then no need to go for nohup , just remove that and try it , hope it will work fine,

Cheers,
Raj.

[Ninad_1]

Hi,

I agree with Raj to some extent.
See the basic purpose of nohup is to allow the process to run and ignore hangups and exits [ which are the signals sents while logging out to all the processes started from your login, if you have logged in and run a command/process ]
When you are scheduling a command/process to run via cron - you are not logging in and logging out, and hence the source of exit and hangup signals is already avoided and hence you need not use nohup through cron. BUT any later exit or hangup signals to the process will not be ignored as you have not used nohup. This may be done by using trap in your script to ignore the hangup and exit signals.
But I feel the most elegant and authentic method if you want to really call it as a daemon would be to follow Clay's advise.

Regards,
Ninad

[D Block 2]

try this by hand and type-in one line (note: no cron here):

nohup /switch/interprete 2>&1 1>/switch/nohup.out &

next run:
tail -f /switch/nohup.out

beak out anything here using tail..

---
next create a parent caller, say do_cron program. In this program it will have one line as above...

30 23 * * * /switch/do_cron

the do_cron will have one line of:
nohup /switch/interpret 2>&1 1>/switch/nohup.out &

I think the parent caller named do_cron will be able to exit via cron with no problem.

If you want, add a second line to do_cron, the last line will be say example:

exit 5


next verify the ReturnCode (rc=) for the cron job #### number.. by looking at the "cron.log"... it might be in /usr/spool/cron directory. do a man cron if you need some help to find the "cron.log" file.. might be at the end of the 'man cron" output.. see the line named "SEE FILES" in the doc.


best regards,
Tom

[Ivan Azuara]

I followed their recommendations about to modify the nohup command into the script and when i executed the script in the command line the Interprete program works fine and the nohup.out file register all the incoming transactions (is an application switch).

But when i invoke the script in the cron scheduler the Interprete program runs fine , but the nohup.out file doesn't registry anything.

More ideas ??

Best Regards!

[A. Clay Stephenson]

Yes, I have a very good idea. Daemonize the process as I indicated with Perl so that it is a real daemon rather than this silly nohup'ed thing that isn't a daemon.

[Denver Osborn]

Clay solved a problem I had! Recently added a new app startup script. At system boot the start script seemed to work fine, but not long after startup completed the process stopped. Looked into it and found that an app script started a few daemons using nohup. So I used Clays perl script to call the vendor's "/app_path/deamons.sh start" script.

Thanks to Clay for the comments on this thread. It pointed me in the right direction and solved the problem.

You should take Clay's advice.

-denver

[Stephen Keane]

Unless of course you don't have perl installed on your machine (n which case beware a beating about the head with a raw haddock from Clay).

[Ivan Azuara]

I understand the intention of the perl script of Clay, but in my case the final user use the nohup.out file like a log file. How can i create this log file without the nohup command.

I have the "perl D.5.8.3.B" installed on the server. If i want to scheduler the perl program, is enough to invoke the program by his name since the cron schedule?.

Sorry but i don´t have experience with perl.

Thank's for your time an advices!

[A. Clay Stephenson]

If you don't know much Perl then that's really not much of a problem. All the modifications that you might need are in the exec() function so modify that to fit your needs and then create a plain ole shell script wrapper to invoke the Perl script including setting any needed environment variables and redirecting stdout, stderr, and/or stdin. The shell script is then what is invoked from cron although I don't quite understand why you think cron is necesssary unless the daemon performs a task and then exits -- which really isn't a daemon.

Your wrapper script might look something like this:

#!/usr/bin/sh
typeset LOGFILE=/var/tmp/myfile${$}.log
typeset ERRFILE=/var/tmp/myfile${$}.err

export PATH=${PATH}:/usr/bin:/usr/local/bin:/opt/perl/bin

export MYVAR=dumbo
export MYVAR2="Mickey Mouse"

typeset -i STAT=0
perl mydaemon.pl > ${LOGFILE} 2>${ERRFILE}
STAT=${?}
exit ${STAT}

[Ivan Azuara]

That's right. I'm triying to automatize a specific task since the cron scheduler, with the purpouse to execute a certain script and the content of this script has defined the nohup command with the intention to create a nohup.out log file.

In fact the Interprete program is an executable C program, that runs like a daemon (maybe is not a good comparison), but this program it must stay running for catching all the incoming transferences, and those transference keep and entry in the nohup.out file.

I don't known if is the best solution for this task, but actually that´s is the form that they work.

Best Regards !

[A. Clay Stephenson]

It sounds as though what you are describing should really not be a cron job. What would prevent multiple processes from being triggered simultaneously. Think about using eith an rc'ed daemon that would be started on system startup or something under the control of init. If you create an inittab entry with an action of "respawn" then as soon as your command terminates it will be restarted automatically.

[A. Clay Stephenson]

It sounds as though what you are describing should really not be a cron job. What would prevent multiple processes from being triggered simultaneously? Think about using either an rc'ed daemon that would be started on system startup or something under the control of init. If you create an inittab entry with an action of "respawn" then as soon as your command terminates it will be restarted automatically. In my above wrapper script example you probably should redirect stdout and stderr in append mode (use ">>" rather than ">") so that the log file is appended rather than recreated each time.