In the control script of my daemon in /etc/init.d?, I have # chkconfig: 35 97 3
The result of this is that I have links: /etc/rc.d/rc1.d/K03... /etc/rc.d/rc3.d/S97... /etc/rc.d/rc5.d/S97...
As mentioned in a previous thread, my complex daemon throws an exception when I shutdown. Perhaps things might be better if I had: /etc/rc.d/rc3.d/K03...
Might this be a good idea? If so, how can I make it happen automatically?
Thanks, Mike.
On Fri, Dec 3, 2010 at 7:30 PM, Michael D. Berger m_d_berger_1900@yahoo.com wrote:
In the control script of my daemon in /etc/init.d?, I have # chkconfig: 35 97 3
The result of this is that I have links: /etc/rc.d/rc1.d/K03... /etc/rc.d/rc3.d/S97... /etc/rc.d/rc5.d/S97...
As mentioned in a previous thread, my complex daemon throws an exception when I shutdown. Perhaps things might be better if I had: /etc/rc.d/rc3.d/K03...
Might this be a good idea? If so, how can I make it happen automatically?
Read the manual page for the "chkconfig" command, and then run: /sbin/chkconfig "scriptname" off
On Sat, 4 Dec 2010, Michael D. Berger wrote:
To: centos@centos.org From: Michael D. Berger m_d_berger_1900@yahoo.com Subject: [CentOS] # chkconfig: kill at run level 3
In the control script of my daemon in /etc/init.d?, I have # chkconfig: 35 97 3
The result of this is that I have links: /etc/rc.d/rc1.d/K03... /etc/rc.d/rc3.d/S97... /etc/rc.d/rc5.d/S97...
As mentioned in a previous thread, my complex daemon throws an exception when I shutdown. Perhaps things might be better if I had: /etc/rc.d/rc3.d/K03...
Might this be a good idea? If so, how can I make it happen automatically?
What I would suggest is using mc file/directory browser:
cd to /etc/init.d/
create a directory called tmp-backups
make a copy of all the init scripts in above directory
Working in /etc/init.d/ find the start/stop script that's giving you problems.
Copy it to another filename, eg (your-initials)-scriptname
(That way any init scripts you add will all be in one place, starting with your initials) and easy to find.
Gut the new script, and use it as a skeleton to create your own init start/stop script.
Decide what you want the script to do at start time, and at stop time.
Alter the parameters for when the script starts and stops, at the top of the file.
Make this script run at shutdown before the main script you copied it from.
You might need to add a shell conditional to prevent the script from shutting down your app straight away at boot time.
Use chkconfig to automatically create the necessary start/stop files for each run level.
See 'pinfo chkconfig'
NAME chkconfig - updates and queries runlevel information for system services
SYNOPSIS chkconfig --list [name] chkconfig --add name chkconfig --del name chkconfig [--level levels] name <on|off|reset|resetpriorities> chkconfig [--level levels] name
DESCRIPTION
chkconfig provides a simple command-line tool for maintaining the /etc/rc[0-6].d directory hierarchy by relieving system administra-tors of the task of directly manipulating the numerous symbolic links in those directories.
You might even be able to create a stop script without the associated start script.
Each start/stop script in /etc/rc0.d - rc6.d is a symlink to the actual script in /etc/init.d/
The rc*.d start scripts have the format:
@S00scriptname
and the stop scripts
@K00scriptname
These scripts are run in ascending numeric order, so you will need to create a kill script (K00myscript) that is numbered befroe the script you want to affect.
Please see this old SuSE documentation for a good description of the Linux boot process:
http://linuxmafia.com/linux/suse-linux-internals/part2.html
HTH
Kind Regards,
Keith Roberts
On Sat, 04 Dec 2010 15:25:47 +0000, Keith Roberts wrote:
[...]
Please see this old SuSE documentation for a good description of the Linux boot process:
[...]
Will this SuSE documentation be correct for CentOS, which is RedHat?
Mike.
On Sat, 4 Dec 2010 20:42:02 +0000 (UTC) "Michael D. Berger" m_d_berger_1900@yahoo.com wrote:
On Sat, 04 Dec 2010 15:25:47 +0000, Keith Roberts wrote:
[...]
Please see this old SuSE documentation for a good description of the Linux boot process:
[...]
Will this SuSE documentation be correct for CentOS, which is RedHat?
I'm not a boot-loader expert, but CentOS uses grub and the first thing I notice about the attached article is that it talks about LILO. From what I've gathered LILO is a different animal than grub, so as far as the documentation is specific to lilo processes, I'd say no it wouldn't be correct for CentOS.
However since the 'li' part of lilo stands for linux, then it may be a good general reference. But some of those more expert in the differences two will probably chime in at some point.
On Sat, 04 Dec 2010 15:58:10 +0000, Cia Watson wrote: [...] 04 Dec 2010 15:25:47 +0000, Keith Roberts wrote:
[...]
I'm not a boot-loader expert, but CentOS uses grub and the first thing I notice about the attached article is that it talks about LILO. From what I've gathered LILO is a different animal than grub, so as far as the documentation is specific to lilo processes, I'd say no it wouldn't be correct for CentOS.
However since the 'li' part of lilo stands for linux, then it may be a good general reference. But some of those more expert in the differences two will probably chime in at some point.
So where can I find a good description of how grub works in RedHat?
Thanks, Mike.
On Sun, 5 Dec 2010 03:41:45 +0000 (UTC) "Michael D. Berger" m_d_berger_1900@yahoo.com wrote:
On Sat, 04 Dec 2010 15:58:10 +0000, Cia Watson wrote: [...] 04 Dec 2010 15:25:47 +0000, Keith Roberts wrote:
[...]
I'm not a boot-loader expert, but CentOS uses grub and the first thing I notice about the attached article is that it talks about LILO. From what I've gathered LILO is a different animal than grub, so as far as the documentation is specific to lilo processes, I'd say no it wouldn't be correct for CentOS.
However since the 'li' part of lilo stands for linux, then it may be a good general reference. But some of those more expert in the differences two will probably chime in at some point.
So where can I find a good description of how grub works in RedHat?
Here's some links I found doing a general search for grub redhat:
http://magazine.redhat.com/2007/03/21/using-grub-to-overcome-boot-problems/
http://www.sorgonet.com/linux/grubrestore
General info:
http://www.gnu.org/software/grub/
This one talks about boot floppies, so it's obviously a little old :-/ http://www.troubleshooters.com/linux/grub/grub.htm
I'm not a boot-loader expert, but CentOS uses grub and the first thing I notice about the attached article is that it talks about LILO. From what I've gathered LILO is a different animal than grub, so as far as the documentation is specific to lilo processes, I'd say no it wouldn't be correct for CentOS.
However since the 'li' part of lilo stands for linux, then it may be a good general reference. But some of those more expert in the differences two will probably chime in at some point.
for the sake of anyone reading this thread in the future...
LILO was the old linux loader. it was used in the original Red Hat Linux until about 7.2.
GRUB is more powerful, more flexible, supports more/newer hardware, and newer/larger file systems, etc etc. All RHEL/CentOS systems have used grub.
Lilo requires boot information to be updated in the MBR each time anything changed. grub can read the grub.conf file in the /boot file system so there's no need to update it when you edit the file.
On 12/04/10 21:42, Michael D. Berger wrote:
On Sat, 04 Dec 2010 15:25:47 +0000, Keith Roberts wrote:
[...]
Please see this old SuSE documentation for a good description of the Linux boot process:
[...]
Will this SuSE documentation be correct for CentOS, which is RedHat?
Mike.
The article largely applies yes, but for the latest and greatest just checkout the start up scripts in /etc. They are not that hard to read.
On Sat, 4 Dec 2010, Michael D. Berger wrote:
To: centos@centos.org From: Michael D. Berger m_d_berger_1900@yahoo.com Subject: Re: [CentOS] # chkconfig: kill at run level 3
On Sat, 04 Dec 2010 15:25:47 +0000, Keith Roberts wrote:
[...]
Please see this old SuSE documentation for a good description of the Linux boot process:
[...]
Will this SuSE documentation be correct for CentOS, which is RedHat?
Well I guess the answer is yes and no, depending on what you are refering to.
I gave you that link specifically for the boot process and how the /etc/init.d scripts figure in the boot process.
The boot process is *probably* the same for most flavours of Linux. Maybe somebody else on this list can comment on that?
If you understand how these scripts work, then you will have more success at modyfying them :)
The good thing about Fedora/RHEL/Centos is the chkconfig script, which does all the hard work of setting up each run-level script for you.
Under SuSE a few years ago, these scripts had to be delat with by hand, IIRC. I know there was no chkconfig on the versions of SuSE I was using ~ 9.2
Kind Regards,
Keith Roberts HNC CDP
On Friday 03 December 2010 19:30, Michael D. Berger wrote:
In the control script of my daemon in /etc/init.d?, I have # chkconfig: 35 97 3
The result of this is that I have links: /etc/rc.d/rc1.d/K03... /etc/rc.d/rc3.d/S97... /etc/rc.d/rc5.d/S97...
As mentioned in a previous thread, my complex daemon throws an exception when I shutdown. Perhaps things might be better if I had: /etc/rc.d/rc3.d/K03...
Might this be a good idea? If so, how can I make it happen automatically?
Check /etc/rc.d/rc6.d and insure that you have K??yourscriptname in there. It looks like your script demon was setup to be run but was never properly setup to be shut down. When shutting down the system the system is switched to run level 6.
On Sun, Dec 5, 2010 at 10:50 AM, Robert Spangler mlists@zoominternet.net wrote:
On Friday 03 December 2010 19:30, Michael D. Berger wrote:
In the control script of my daemon in /etc/init.d?, I have # chkconfig: 35 97 3
The result of this is that I have links: /etc/rc.d/rc1.d/K03... /etc/rc.d/rc3.d/S97... /etc/rc.d/rc5.d/S97...
As mentioned in a previous thread, my complex daemon throws an exception when I shutdown. Perhaps things might be better if I had: /etc/rc.d/rc3.d/K03...
Might this be a good idea? If so, how can I make it happen automatically?
Check /etc/rc.d/rc6.d and insure that you have K??yourscriptname in there. It looks like your script demon was setup to be run but was never properly setup to be shut down. When shutting down the system the system is switched to run level 6.
This is not uncommon: some init scripts merely set up initial conditions, such as the "freenx" init script that assures that /tmp/.X11-unix is configured correctly for NX's necessary X sessions.
Others were written by crack monkeys who wouldn't know how to properly start or stop a daemon if it came with a toggle switch and signes in six languages: they just slap somethin in "rc.local", then someone makes them transfer it to a real init script, and someone else has to clean up the mess.
That's happened several times to me recently. You do *not* add system users in init scripts, and you don't "cd" to directores that might not be successfully NFS mounted, then run "rm" commands wherever your failed "cd" wound up. This way lies system destruction.
On Sun, 05 Dec 2010 10:50:53 -0500, Robert Spangler wrote:
On Friday 03 December 2010 19:30, Michael D. Berger wrote:
[...]
Check /etc/rc.d/rc6.d and insure that you have K??yourscriptname in there. It looks like your script demon was setup to be run but was never properly setup to be shut down. When shutting down the system the system is switched to run level 6.
The correct K link does appear in /etc/rc.d/rc6.d . I wrote a "stop" script that stops my daemon, does sleep 5, and then calls shutdown (or reboot). I don't like this kluge, but it does work. Could it be that my daemon stop procedure is too slow or complex for shutdown? The TERM code does send stop messages to and join several threads, which in turn do the same to nested threads. Each thread does some stop logging, among other things.
Mike.
On Sun, Dec 5, 2010 at 10:46 PM, Michael D. Berger m_d_berger_1900@yahoo.com wrote:
On Sun, 05 Dec 2010 10:50:53 -0500, Robert Spangler wrote:
On Friday 03 December 2010 19:30, Michael D. Berger wrote:
[...]
Check /etc/rc.d/rc6.d and insure that you have K??yourscriptname in there. It looks like your script demon was setup to be run but was never properly setup to be shut down. When shutting down the system the system is switched to run level 6.
The correct K link does appear in /etc/rc.d/rc6.d . I wrote a "stop" script that stops my daemon, does sleep 5, and then calls shutdown (or reboot). I don't like this kluge, but it does work. Could it be that my daemon stop procedure is too slow or complex for shutdown? The TERM code does send stop messages to and join several threads, which in turn do the same to nested threads. Each thread does some stop logging, among other things.
Mike.
"Taking too long" is unlikely. Running through the shutdown init scripts is normally a serial operation, not a parallel one.
It could be that your shutdown script is simply incomplete, and fails to *finish* stopping a process before proceeding to the next one. If you wait on each threed to stop, surveying it for status and killing it whan an ax only if necessary, then you may have a better fighting chance of getting it shut down gracefully.
I've had some recent work with init scripts that weren't written as init scripts, that get confused and hang ridiculously awaiting further input. Issuing yet another "shutdown" or "reboot" command at that point will simply re-run your shutdown procedures, especially this shutdown script: that way can lie madness if your "threads" aren't shut down gracefully.
It sounds like you need more thorough logging of what your shutdown script does.....
On Mon, 06 Dec 2010 01:30:12 -0500, Nico Kadel-Garcia wrote:
On Sun, Dec 5, 2010 at 10:46 PM, Michael D. Berger m_d_berger_1900@yahoo.com wrote:
On Sun, 05 Dec 2010 10:50:53 -0500, Robert Spangler wrote:
On Friday 03 December 2010 19:30, Michael D. Berger wrote:
[...]
Check /etc/rc.d/rc6.d and insure that you have K??yourscriptname in there. It looks like your script demon was setup to be run but was never properly setup to be shut down. When shutting down the system the system is switched to run level 6.
The correct K link does appear in /etc/rc.d/rc6.d . I wrote a "stop" script that stops my daemon, does sleep 5, and then calls shutdown (or reboot). I don't like this kluge, but it does work. Could it be that my daemon stop procedure is too slow or complex for shutdown? The TERM code does send stop messages to and join several threads, which in turn do the same to nested threads. Each thread does some stop logging, among other things.
Mike.
"Taking too long" is unlikely. Running through the shutdown init scripts is normally a serial operation, not a parallel one.
It could be that your shutdown script is simply incomplete, and fails to *finish* stopping a process before proceeding to the next one. If you wait on each threed to stop, surveying it for status and killing it whan an ax only if necessary, then you may have a better fighting chance of getting it shut down gracefully.
I've had some recent work with init scripts that weren't written as init scripts, that get confused and hang ridiculously awaiting further input. Issuing yet another "shutdown" or "reboot" command at that point will simply re-run your shutdown procedures, especially this shutdown script: that way can lie madness if your "threads" aren't shut down gracefully.
It sounds like you need more thorough logging of what your shutdown script does.....
I think that I am missing something. In my script in /etc/init.d :
stop) echo -n "Stopping $myThing: " killproc -d 5 $myThing_prog sleep 30 echo rm -f $VAR_SUBSYS_MYTHING ;;
The sleep 30 is not usually there, but it didn't make any difference. There certainly was not a 30 second delay in the shutdown sequence.
I also put a sleep(30) in the TERM signal processor and there was no difference. (BTW, the daemon is in C++.)
When you say the shutdown runs through the scripts sequentially, then why didn't my sleeps work? When I call the stop for my daemon without shutting down, there is no problem.
BTW, it is K03 ...
Thanks, Mike.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Robert Spangler Sent: Sunday, December 05, 2010 10:51 AM To: CentOS mailing list Subject: Re: [CentOS] # chkconfig: kill at run level 3
On Friday 03 December 2010 19:30, Michael D. Berger wrote:
In the control script of my daemon in /etc/init.d?, I have # chkconfig: 35 97 3
The result of this is that I have links: /etc/rc.d/rc1.d/K03... /etc/rc.d/rc3.d/S97... /etc/rc.d/rc5.d/S97...
As mentioned in a previous thread, my complex daemon throws an exception when I shutdown. Perhaps things might be better
if I had:
/etc/rc.d/rc3.d/K03...
The number after the S and K determine the order in which they're run. S01 starts things which S02-S99 might require; S02 might depend on S01 and provide service the S03-S99 stuff requires. And, so on. The K scripts *generally* follow the reverse order on the logic that nothing is shut down while something else might require it. Therefore a service with S01 has K99, what is S02 has K98, and so on.
I'd (personally) guess at the Wild Blue that your Kxx kill script has a high enough number that it's shutting your app down after something else has been shut down, on which your app depends, without which your app throws an exception. That's why (guess based on previous guess) if you kill your app then shut down, everything is happy.
General Rule of Thumb: Sxx -> K(100-xx)
******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
On Mon, 06 Dec 2010 11:38:49 -0500, Brunner, Brian T. wrote:
[...
The number after the S and K determine the order in which they're run. S01 starts things which S02-S99 might require; S02 might depend on S01 and provide service the S03-S99 stuff requires. And, so on. The K scripts *generally* follow the reverse order on the logic that nothing is shut down while something else might require it. Therefore a service with S01 has K99, what is S02 has K98, and so on.
I'd (personally) guess at the Wild Blue that your Kxx kill script has a high enough number that it's shutting your app down after something else has been shut down, on which your app depends, without which your app throws an exception. That's why (guess based on previous guess) if you kill your app then shut down, everything is happy.
General Rule of Thumb: Sxx -> K(100-xx)
It is K03...
Mike.
-
Brunner, Brian T. -
Cia Watson -
John R Pierce -
Keith Roberts -
Michael D. Berger -
Nico Kadel-Garcia -
RedShift -
Robert Spangler