LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices



Reply
 
Search this Thread
Old 08-17-2009, 03:19 AM   #16
sanitynotvanity
Member
 
Registered: Jul 2007
Location: UK
Distribution: LFS 6.8, Android, Ubuntu 10.10, XP, 7 (HB,HP,Ultimate)
Posts: 41

Original Poster
Rep: Reputation: 15

Hi Sasha,

Sorry for late reply. I was out this weekend without a computer to reply or even to try this out with!

Quote:
Originally Posted by GrapefruiTgirl View Post
That is almost certainly because you weren't passing the (other required) arguments to the `reboot` or `shutdown` binaries, as would normally be done. Check the man page(s) for reboot and/or shutdown for the arguments you would need for them to operate properly as you want them to.
I thought this too, but the 'reboot' and 'poweroff' were never their own binaries. they were just symlinks to the halt script. Even still, in my attempts i used a '$*' to forward any params. but that never made a difference. I also tried $0 to pass the filename as a parameter but this cause adverse behaviour of which i can't quite remember.

Quote:
Originally Posted by GrapefruiTgirl View Post
OK, I'm not sure I fully understand about that, but see the last paragraph again. FWIW, I'd put the system scripts back as they were, and look freshly at this..

it's pretty easy; here's a sample:

Code:
bash-3.1$ alias reboot=hello
bash-3.1$ reboot
bash: hello: command not found
bash-3.1$
So you see, I made it so when I type 'reboot' it actually tries to execute the command 'hello'. You can set up aliases in ~/.bashrc or /etc/profile or bash_profile or one of these files -- might vary per system..

Not an "alias script" -- just an 'alias' -- but if you want to type 'reboot' and have it do your stuff and then reboot, then you need to make a script called "whateverscript" and then make an alias like:

Code:
bash-3.1$ alias reboot=/path/to/whateverscript
So if you type reboot it will execute your script, called "whateverscript", which will execute your funny mysterious commands, and THEN the whateverscript calls /sbin/reboot with the options you put in the whateverscript.


If applications (like 3rd party stuff that depends on a 'reboot' command being on the system) want to reboot the machine, it will still work; but YOUR SPECIAL STUFF will be executed first.

If I understand what's going on here (and I'm not 100% sure I do) then the script I showed you should work, if you tweak it to your exact needs..

Here's what you want, to my understanding (no matter who/how/what/why/what wants to reboot the machine):

1) kill some applications.
2) remove some modules (not necessarily in this order)
3) .. now reboot the machine.

so make an alias as above, so 'reboot' is aliased to the script, and make the script like the one I provided.

I hope I've got this all right as I'm confused now

NOTE: some system tools, like scripts particularly, will literally call "/sbin/reboot" using the full absolute path, in which case aliasing will not change anything.
In that case (to ensure that this does not happen and your funny stuff ALWAYS gets executed) then rename the 'reboot' system binary in /sbin to something else, and then put your whateverscript in /sbin and name it 'reboot' and all will be well. That way, no matter how /sbin/reboot gets called, your whateverscript will be executed. But MAKE SURE YOU DO SANITY CHECKING and grab any options/arguments that are passed to your script, so that you can pass them along to the real reboot binary after having done your funny stuff.

Sasha
Brilliant, i think you have fully understood my problem

I'm going to try this now, will let you know how I get on.

What constitutes as sanity checking??

Thanks for the help
 
Old 08-17-2009, 03:42 AM   #17
sanitynotvanity
Member
 
Registered: Jul 2007
Location: UK
Distribution: LFS 6.8, Android, Ubuntu 10.10, XP, 7 (HB,HP,Ultimate)
Posts: 41

Original Poster
Rep: Reputation: 15
[solved]

Yipeee! it works

Here is my code, including how I have forwarded on the params. Can you see any problems with that?

i tried reboot -f and that appeared to work as expected

Code:
#!/bin/bash

# Begin /sbin/venicereboot
# Description: enforces the stopping of GC before reboot
# Author: Andrew Barnes

PARAMS=$*
echo "Halting any Generic Controller processes that may be in operation..."
gcstop

/sbin/reboot $PARAMS

# End /sbin/venicereboot
 
Old 08-17-2009, 04:14 AM   #18
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,563
Blog Entries: 29

Rep: Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179
Better
Code:
#!/bin/bash

# Begin /sbin/venicereboot
# Description: enforces the stopping of GC before reboot
# Author: Andrew Barnes

echo "Halting any Generic Controller processes that may be in operation..."
gcstop

/sbin/reboot "$@"

# End /sbin/venicereboot
The original will set PARAMS to the first parameter then try to run the rest as a command.

From the GNU Bash Reference Manual @ Expands to the positional parameters, starting from one. When the expansion occurs within double quotes, each parameter expands to a separate word. That is, "$@" is equivalent to "$1" "$2" ...."
 
Old 08-17-2009, 04:16 AM   #19
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,563
Blog Entries: 29

Rep: Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179
Quote:
Originally Posted by sanitynotvanity View Post
there is some subtle difference between a symlink and a bash script call in the way that the called program can interrogate its caller.
Interesting! What's the difference and how was it significant?
 
Old 08-17-2009, 05:21 AM   #20
sanitynotvanity
Member
 
Registered: Jul 2007
Location: UK
Distribution: LFS 6.8, Android, Ubuntu 10.10, XP, 7 (HB,HP,Ultimate)
Posts: 41

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by catkin View Post
Better
Code:
#!/bin/bash

# Begin /sbin/venicereboot
# Description: enforces the stopping of GC before reboot
# Author: Andrew Barnes

echo "Halting any Generic Controller processes that may be in operation..."
gcstop

/sbin/reboot "$@"

# End /sbin/venicereboot
The original will set PARAMS to the first parameter then try to run the rest as a command.

From the GNU Bash Reference Manual @ Expands to the positional parameters, starting from one. When the expansion occurs within double quotes, each parameter expands to a separate word. That is, "$@" is equivalent to "$1" "$2" ...."

I am confused. At first i thought it made sense because $* would include $0 which is the filename.

so the result might have been:

Code:
/sbin/reboot reboot <params...>
or
Code:
/sbin/reboot venicereboot <params...>
depending on how that alias works...

but when i ran a simple script to echo the differences between each method:

Code:
echo "1"
echo $*

echo "2"
echo "$*"

echo "3"
echo $@

echo "4"
echo "$@"
Code:
test -r -f- 400 300
the results were:

Code:
1
-r -f 400 300
2
-r -f 400 300
3
-r -f 400 300
4
-r -f 400 300
so now i dont understand...
 
Old 08-17-2009, 05:24 AM   #21
pwc101
Senior Member
 
Registered: Oct 2005
Location: UK
Distribution: Slackware
Posts: 1,847

Rep: Reputation: 128Reputation: 128
I've not read the entire thread, but couldn't you just place your command in /etc/rc.d/rc.local_shutdown which, if executable, will get executed each time before a shutdown/reboot?
 
Old 08-17-2009, 05:56 AM   #22
sanitynotvanity
Member
 
Registered: Jul 2007
Location: UK
Distribution: LFS 6.8, Android, Ubuntu 10.10, XP, 7 (HB,HP,Ultimate)
Posts: 41

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by catkin View Post
Interesting! What's the difference and how was it significant?
well thats what has kept me on my toes for the last few days.

Unfortunately, i still don't really know.

Originally system had one halt script, with two symbolic links called reboot and poweroff.

When those symbolic links were exectuted the halt script was able to determine which symbolic link was the caller (although, I appreciate this terminology may not be technically accurate).

the halt script is written in C and uses argv[0] to determine the ...

wait i've just worked it out - DOH

---

you have to think of the symbolic link as the actual file. So in the case of executing reboot, you are actually executing halt but you've called it reboot. So when halt looks at its C equivalent to $0, the first parameter, it sees what is normally its own name as the symbolic name.

Thus, when i tried to place mediating script in-between the halt script was seeing its first parameter as "halt". because i actually called halt from my mediating script.

I feel the penny has clicked
 
Old 08-17-2009, 06:11 AM   #23
sanitynotvanity
Member
 
Registered: Jul 2007
Location: UK
Distribution: LFS 6.8, Android, Ubuntu 10.10, XP, 7 (HB,HP,Ultimate)
Posts: 41

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by pwc101 View Post
I've not read the entire thread, but couldn't you just place your command in /etc/rc.d/rc.local_shutdown which, if executable, will get executed each time before a shutdown/reboot?
Not a script option that i knew of before. However, the real-time modules that are in use are incredibly unstable when the system starts trying to change runlevels. (and many other things).

This is why i set out to avoid using the init system.

I assume it would not work..

Last edited by sanitynotvanity; 08-17-2009 at 06:12 AM. Reason: Speeling error ;)
 
Old 08-17-2009, 08:58 AM   #24
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,563
Blog Entries: 29

Rep: Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179
This script will illustrate the differences
Code:
echo '$*'
for arg in $*
do
    echo "'$arg'"
done

echo '"$*"'
for arg in "$*"
do
    echo "'$arg'"
done

echo '$@'
for arg in $@
do
    echo "'$arg'"
done

echo '"$@"'
for arg in "$@"
do
    echo "'$arg'"
done
Then call it including arguments with embedded whitespace
Code:
test -r -f- 400 '300 200'
test -r -f- 400 "300${IFS}200'
 
Old 08-17-2009, 09:00 AM   #25
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550
Quote:
Originally Posted by sanitynotvanity View Post
Not a script option that i knew of before. However, the real-time modules that are in use are incredibly unstable when the system starts trying to change runlevels. (and many other things).

This is why i set out to avoid using the init system.

I assume it would not work..
Don't quote me about the exact place in the shutdown sequence where rc.local.shutdown gets executed, but:

I think the OP's correct, this won't do what you want -- it'll put you right back at the start of all this, because rc.local.shutdown gets executed too late AFAIK. Plus, it depends on the init system too.

?? ??

Sasha
 
Old 08-17-2009, 09:23 AM   #26
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,563
Blog Entries: 29

Rep: Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179
I like the concept of replacing /sbin/reboot with a script that calls the original /sbin/reboot (and a /sbin/halt symlink to the same script, mimicking the /sbin/halt symlink to /sbin/reboot) because it allows for running gcstop before halting or initiating reboot regardless of how reboot or halt are called -- from the command prompt or via the init mechanism. It's a minimal intervention method.

sanitynotvanity wrote
Quote:
However, the real-time modules that are in use are incredibly unstable when the system starts trying to change runlevels. (and many other things)
What is the basis for that? What is it about the init shutdown and reboot mechanism that changes the system in such a way as to make the real-time modules (gc?) more unstable when the system starts changing runlevels. Perhaps my ignorance but I am not aware that it changes anything significant before running the script pointed to by the first /etc/init[06].d/K* symlink. Hence I do not understand why the conventional mechanism to issue the gcstop command cannot be used. This has the advantage over front-ending /sbin/reboot of issuing the gcstop command early in the shutdown-or-reboot process, while the running system is closer to normal, before any other system facilities have been shut down.

Sometimes it is more useful to question the assumptions rather than offer solutions.
 
Old 08-17-2009, 11:17 AM   #27
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,775

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
rc.0 is usually a symplink to rc.6. The actual script(rc.6) then determines which name it was called by. If rc.local_shutdown gets run too late, then simply remove the rc.0 link and replace it with a copy of rc.6 named rc.0. Then you can alter either or both of them as needed to run your commands at the appropriate time. However, if you are shutting down from a GUI session, then you will have already changed runlevels by the time rc.0/6 gets run. If that's the case, then you'd still need to use some other method to be sure your commands get run before changing runlevel.
 
Old 08-17-2009, 11:46 AM   #28
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,563
Blog Entries: 29

Rep: Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179
Quote:
Originally Posted by gnashley View Post
rc.0 is usually a symplink to rc.6. The actual script(rc.6) then determines which name it was called by. If rc.local_shutdown gets run too late, then simply remove the rc.0 link and replace it with a copy of rc.6 named rc.0.
Are we into distro differences here? On ubuntu 8.04 there is no rc.0 or rc.6 and both /etc/rc0.d and /etc/rc6.d are directories containing symlinks to scripts in /etc/init.d/
Quote:
Originally Posted by gnashley View Post
However, if you are shutting down from a GUI session, then you will have already changed runlevels by the time rc.0/6 gets run.
I'd like to know more about that, especially what actions happen when shutting down from a GUI session. AIUI (I stand to be corrected), init's first action on being asked to change run level is to run the scripts pointed to by the K* symlinks in the new run level's /etc/rc[S0-6].d directory.

I have a particular reason for asking, detailed in this zero-reply thread.
 
Old 08-17-2009, 09:28 PM   #29
chrism01
Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.6, Centos 5.10
Posts: 16,324

Rep: Reputation: 2041Reputation: 2041Reputation: 2041Reputation: 2041Reputation: 2041Reputation: 2041Reputation: 2041Reputation: 2041Reputation: 2041Reputation: 2041Reputation: 2041
Here's a really good Start/Stop tutorial http://www.yolinux.com/TUTORIALS/Lin...itProcess.html

Generally, actual scripts are in /etc/rc.d/init.d dir (at least on Redhat compatible/ classic SysV based systems).
The symlinks for each level exist in /etc/rc.d/rcX.d (X = runlevel eg 3) and point to the actual scripts in /etc/rc.d/init.d.

Quote:
Note that two lines in the script enable the chkconfig command to control the script for the boot and shutdown process.

# chkconfig: 345 85 15
# description: Description of program


When added to the boot process using the "chkconfig --add script-name" command the start order/priority will be set to 80 while the stop/shutdown order will be set to 15. The process will be added to runlevels 3, 4 and 5. This is enabled by generating links from the location of the script (/etc/rc.d/init.d/) to the directory for the appropriate run level: /etc/rc.d/rc#.d/. The file name in the run level directory will reflect if it is used for boot (starts with an "S") or shutdown (starts with a "K")
I think you'll find the start (S) and stop (K = kill) links will be in the same dir for for a given service for each runlevel.
 
Old 08-18-2009, 05:18 AM   #30
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Servers: Debian Squeeze and Wheezy. Desktop: Slackware64 14.0. Netbook: Slackware 13.37
Posts: 8,563
Blog Entries: 29

Rep: Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179Reputation: 1179
Thanks for the link, chrsim01
Quote:
Originally Posted by chrism01 View Post
I think you'll find the start (S) and stop (K = kill) links will be in the same dir for for a given service for each runlevel.
Not usually. When changing run levels the procedure is to run all the scripts pointed to by the K* links in the new run level directory followed by all the S*. This usually results in the S and K links for any one package being in different directories.

For evidence of this, see the example INIT INFO at the bottom of LSB - Comment Conventions for Init Scripts and this from an ubuntu 8.04 system
Code:
c@CW8:~$ ls -l /etc/rc[0-6].d/*gdm* | cut -c44-
/etc/rc0.d/K01gdm -> ../init.d/gdm
/etc/rc1.d/K01gdm -> ../init.d/gdm
/etc/rc2.d/S30gdm -> ../init.d/gdm
/etc/rc3.d/S30gdm -> ../init.d/gdm
/etc/rc4.d/S30gdm -> ../init.d/gdm
/etc/rc5.d/S30gdm -> ../init.d/gdm
/etc/rc6.d/K01gdm -> ../init.d/gdm
Thus the combination of K* and S* links in any run level define what is not required and what is required in that level.
 
  


Reply

Tags
halt, poweroff, reboot


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to extend the poweroff and reboot process? (without using sysvinit) sanitynotvanity Linux From Scratch 2 08-13-2009 10:57 AM
reboot/poweroff how? demmylls Linux - General 2 08-13-2009 10:52 AM
Annoying message during reboot or poweroff janas03 Slackware 8 04-24-2008 06:05 AM
Panic; reboot/poweroff; 2.4.33.3 Tralce Linux - Kernel 0 12-04-2006 03:54 PM
reboot vs poweroff??? bigdog0007 Linux - Newbie 4 09-16-2005 03:48 AM


All times are GMT -5. The time now is 01:18 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration