910912 - how can i know that linux is shutting down?
 

i've a perl script in which i need to know whether the system is shutting down. how can i figure it out?
the script is designed to be run in startup and when shutting down (rc.d)...

if your monitor turns off
or the light on the power button turns off
or if the computer powers down ......

</smart_aleck> :rolleyes:

It depends on your distribution, which scripts are executed when the system switches the runlevels.

Read the documentation for your distribution and find out which script runs when the system boots (for example in Slackware /etc/rc.d/rc.S) and when the system is shut down (in Slackware /etc/rc.d/rc.0)
Then put a line into these scripts which execute your perl-script.

Markus

You could let the script take an argument. Then in the startup script you could give it the "start" argument and when called from the shutdown script you could give it the "stop" atgument. This is pretty much just like how any other init script works.

thx 4 replying,
John: oh man! i know what is happening. the matter is that the perl script knows it too.
Habitual: hmm, u mean autodie causes the changed environment variables get applied to the whole shell?
i don't want the perl script be died abnormally. does it cause such a behavior?
markush & btmiller: it's Ubuntu 10.10. it's a written project we're applying changes on. a shell script located on /etc/rc0.d to /etc/rc6.d run a perl script with 'start' or 'stop' argument. the perl script uses a pm (perl module?) file named Config.pm. the decision must be made in the pm file which i don't know how is executed and i think the argument is not passed to it like the main perl script.
if you're familiar with ZoneMinder, zmpkg.pl is the main script and the Config.pm is located on /usr/share/perl/5.10/ZoneMinder.
about the shell script which starts with S20 or K20 in /etc/rcx.d, it's weird that just existence is selectable. otherwise, all these scripts indeed are the same, so that change in one affects of others!

Habitual: i tried it; no change

Ignore me on that reply.
I was kidding. ;)

Markus is spot-on.
What OS are you dealing with?

i told u
it's ubuntu 10.10

hamidi2, did you find out how Ubuntu organizes the startup scripts and the shutdown scripts? could you find out which script runs when you want your perlscript to be executed?

Markus

yes, but the problem is that when the package is installed it creates links to '/etc/init.d/app.sh' in all rc*.d directories. i don't know how this happens and how to change this behavior. for example, if i know how to tell package installer to install separate shell scripts for startup and non-startup conditions, it may resolve my problem.
in another hand, i've heard that there's no difference in runlevel between when the system is starting up and when i manually run the script. in another words, i can't distinguish between them in the shell script.
the IDEAL is that the SYSTEM ITSELF decide to run the shell script at startup after MySQL gets ready to operate and acknowledge requests. if this may happen, i've not to check about it in the shell script at all and the problem will be resolved with a better behavior.

It sounds like its installing correctly. All you need to do is adjust the SXX number of each entry in each dir so that it starts AFTER mysql, instead of before it (& vice versa for shutdown/KXX links)

Eg on my system, I have /etc/rc3.d/S64mysqld, so I'd edit newapp link to be S65newapp

ur right, but in Ubuntu mysql starts differently. sysv is old and a new replacement is putting mysql.conf in /etc/init. i'm not sure which directory is paid attention first, /etc/init or /etc/init.d. but my script is old style. i've to use the same method u mentioned for it, but it doesn't differ what number i assign. i assigned 98 02 so that it be the later one. but sometimes it works and sometimes it doesn't.
note that even starting before mysql is not enough! because it takes time for mysql to get ready.
i used this method:
i wait 60 seconds in a loop in which i check mysql each second. the startup problem is solved.
the shutdown process executes the same script. when it reaches the wait loop mysql has ended. so shutdown process takes one minute to accomplish and times out. for this not to take place i check errorlevel:
i hope mysql get ready to work in at most one minute in all systems.