script called from inittab cannot find files in current directory 3

[svar]

I have a working script(in perl) that runs fine in /home/me/mydirectory
Now since this should be running continously with no administration,I want this to run automatically if say the computer shuts down and is restarted. So I put in /etc/inittab
myjob:3456:respawn:/home/me/scriptcaller

which says
#!/bin/bash
cd /home/me/mydirectory
su - me -c "perl /home/me/mydirectory/myscript.pl"

The script runs, except that it cannot find data files like
myfile in /home/me/mydirectory/
-by opening and writing to a file, I confirmed that it only looks in /home/me

I thought I hqad taken care of this by putting
/home/me/mydirectory in $PATH, both in /etc/profile and
in .bashrc

What am I missing here?

 

[svar]

Agreed. But in my case the "program" is the shell script,
which does runin the foreground. It dies in less than a second(save for the sleep) and is restarted again.
What you are saying, I guess is that the "program" could have been the perl script, i.e. in init one might have
myscr:3456:respawn:su - me -c "perl /home/me/mydirectory/myscript.pl > /dev/null "
with the cd in the perl script,(I am not sure if we can
"have cd ...; perl...." in the init. In principle yes,
but it is a bit messier

 

[thedaver]

re: daemontools install...

I have documented the qmail install process for RH platforms, I use these intructions - which include a fix for broken errno on that lib/platform

cd /usr/src/qmail
wget [URL unfurl="true"]http://cr.yp.to/daemontools/daemontools-0.76.tar.gz[/URL] 
mkdir -p /package
chmod 1755 /package
cd /package
tar xzfp /usr/src/qmail/daemontools-0.76.tar.gz
cd admin/daemontools-0.76 

# repair broken errno declarations as being INT
# see [URL unfurl="true"]http://article.gmane.org/gmane.mail.qmail.general/13960[/URL]

vi /package/admin/daemontools-0.76/src/error.h

# replace string “extern int errno;”
# with  #include <errno.h>

package/install

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[jgunkel]

svar,

The way that Unix-y job control works is that if you have a shell script and run a program (without the &) from that shell script, it will run, and the shellscript will not exit until that child process exits, and the rest of the script completes.

If you have a shell script which launches a program to the background (with the &) the shell completes the rest of the commands in the script and exits, even though the child process is still running.

So what it sound like is happening to you is that init fires up, looks at the inittab, kicks off the shell script, which starts the perl program in the background. The shell script then completes and exits, leaving your perl script running. At this point, init sees that the shell script has terminated, and will respawn it.

Getting rid of the ampersand from the shell script will prevent the perl script from going to the background, and will give you the desired behavior.

 

[svar]

Ok, I'm still unsure if I should stay with init or go with daemontools. Now daemontools was installed ok,
but from the site, I am unsure as to how to specify that I want to run
(from /home/me/mydirectory the script
perl myscript.pl

and respawn if it dies or when the computer boots)
Any examples?

 

[thedaver]

svar;

The script you use for daemontools is AUTOMATICALLY launched by 'svc' (the daemontools controller) at boot and at crash/respawn.

If it is a perl script (that does "cd ~" within itself)...

http://www.nabble.com/perl-programs-hang-if-run-with-daemontools-t42664.html

Take for example, this script that sends email out from a qmail installation

#!/bin/sh
exec env - PATH="/var/qmail/bin:$PATH" qmail-start ./Maildir/

You could modify the "qmail-start ./Maildir/" to be your "perl myscript.pl"

I assume your script is already structuring using

while [ 1 ] do
....

So that it runs forever.











D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[svar]

So, if I understand correctly(I'm at work and although this is for work, the link is classified as chat and blocked),
once daemontools is installed, svc is running as soon as the machine boots.
Now, how does svc know where to look for scripts to execute
Yes, the (perl) script runs forever

So, the question is:
suppose I create a script myscript whose contents are

#!/bin/sh
exec env - PATH="/home/me/mydriectory:$PATH" perl myscript.pl


(since the perl script is run from /home/me/mydirectory)

a) do I need a special name for that script
b) where do I put that script so that svc knows to find and execute it?

 

[thedaver]

OK, so the DJB manual on USCPI and daemontools is notoriously bad... so here's the beef on installing and configuring in more detail to support qmail... you'll simply change your 'run' script... look for the references to 'run' as the script you need to populate with what we discussed above.

# build and start daemontools as above.

mkdir -p /var/qmail/supervise/qmail-send/log
chmod +t /var/qmail/supervise/qmail-send

# create your script as /var/qmail/supervise/qmail-send/run
# Also create the LOG script in next code set.



chmod 755 /var/qmail/supervise/qmail-send/run
chmod 755 /var/qmail/supervise/qmail-send/log/run

# Update cron to manage log rotation

crontab -e
# the following lines rotate the qmail log files daily
0 0 * * * /usr/local/bin/svc -a /service/qmail-send/log

# Enable qmail under supervise

ln -s /var/qmail/supervise/qmail-send /service

# /var/qmail/supervise/qmail-send/log/run

#!/bin/sh
# Keep 30 logs of max 10Mb each
#
# They will get rotated when they reach 10Mb in size,
# or at midnight when our crontab script fires (whichever event comes 1st)
exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t s10000000 n30 /var/log/qmail/send

This is using a user of 'qmaill', and folder names around a qmail install, you should be able to tailor your scripting to meet your env.

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[svar]

In the crontab, what appears in your post is
0 0 * * * /usr/local/bin/svc -a /service/qmail-send/lo

but I assume you meant
0 0 * * * /usr/local/bin/svc -a
/service/qmail-send/log/run

, correct?

Ok, so if I read you correctly what I need to do(I imagine
setting the sticky bit is not necessary for daemontools, just protection against deletion from anyone but the owner)
is:
1) make sure user "me" is in /usr/lib/cron/cron.allow,
since the perl script runs as user "me"
2) In the perl script set at the very start $|=1
to avoid buffering problems
3) in the crontab there should be a line

* * * * * /usr/local/bin/svc "perl /home/me/mydirectory/myscript.pl"

or should svc run a script that would call perl?
also, is this run as root or me?

 

[thedaver]

svar, yes you caught a typo in my cut-and-paste

DO NOT DO #3!!!

the daemontools daemon is itself instantiated and monitored by inittab. the daemontools core looks like this in "ps waux"

/bin/sh /command/svscanboot
svscan /service

Note that second prog, 'svscan', it is "watching" the /service folder for what to manage.

Further down "ps waux" you'll find

supervise qmail-send
supervise log

This tells you that the ..../run and ..../log/run files are being supervised.

once you did this:

# Enable qmail under supervise

ln -s /var/qmail/supervise/qmail-send /service

You enabled the svscan to look for your script in /service and then 'supervise' is running it...

The 'svc' command itself is a means, much like an init script in /etc/rc.d/init.d/ that controls the services/progs being monitored by svscan/supervise.

The service's script (your link from /service) is first launched by user 'root'

This is why my example log script contains "/usr/local/bin/setuidgid qmaill" this is effectively "sudo'ing" to the desired user and running the script line that follows.

Since your perl script is a "run forever" script, do not use a "&" to background the task.


D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[svar]

Thanks thedaver,
this changes things a bit.(just as I though I was getting the hang of it) I found some people who use
daemonjobs and they said basically step #3 is what they do.
The only change I understand I'd have to make is make sure the right directory is used, i.e.
* * * * * /usr/local/bin/svc "cd /home/me/mydirectory; perl myscript.pl > /dev/null"
(or probably ..
* * * * * /usr/local/bin/svc su -c me "cd /home/me/mydirectory; perl myscript.pl > /dev/null"
(I probably need " before su -c me and at the end (double quotes?)


but if I understand your post right, svc is already running(started by init), so there is no need to start
another instance. I also was worried "well, dont' I need su -c me first"? , but the people I found said no.
Hard to understand how svc can know as what user I need to run myscript(just cause it's in /home/me/mydirectory does not mean it was meant to be run thusly)

Instead you are proposing to
1) create a directory /service (chmod 777 is ok?)
2) specify
a script that will be under supervision by daemontools
(like qmail),

but it is not clear to me
-if supervise is a daemontool command or a system command I am unfamiliar with
- should I put a shell script there that actually calls the perl script?

 

[thedaver]

Do it however you want and however it works...

What's puzzled me in your thread is your insistence to perform

"cd /home/me/mydirectory; perl myscript.pl "

You should/could either hard code the /home/me/mydirectory as the first line of the perl script (perl can change working directories) or you can make it a parameters to the myscript.pl and make the cd change from within perl using an ENV variable..

Thus:
"perl myscript.pl" # hardcode the working dir
"perl myscripl.pl /path/to/folder" # parameter for working dir


I'm not comfortable with the implementation your other sources are advocating, but ultimately you'll have to test and satisfy yourself.
Good luck.


D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[svar]

I started reading, but I need to experiment myself like you said.
Form what I read, your version makes sense.
I checked that /service is there, so I must play with it.
Maybe I'll check back with you. At any rate, thanks both to you and jgunkel