RC scripts in Redhat 1

[GaijinPunch]

I've not used Redhat in a long time, but am having a problem with one of the older boxes. I've put an rc script in /etc/rc3.d, but it doesn't seem to be starting. If I run it manually, it starts fine. I of course, don't want to do this every day. I see no useful output in the ssytem log either.

 

[stefanwagner]

You normally put the scripts in /etc/init.d and link it symbolic to rc3.d/SNNfoo.

Possible problems:
It's not executable.
You're running in a different runlevel.
You don't stick to the name-scheme SNN (NN being digits from 0-9, S for starting, K for Killing (stopping)).



seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung

 

[clonny2]

To put a script in rc.[X], is usually a link, but more important is the name. The name must be S or K with numbers. That tells init where in the runlevel to run its script.

Example, S10network means that as rc3 goes through the start scripts, they are sorted by when the start, lowest starting first. If There are multiple scripts with the same number like S10, they are next sorted alphabetically. S10a starts before S10z.

Also look at chkconfig. If your script is correctly configured then chkconfig will create all of the links in the rc levels.

Look at the line #chkconfig in one of the scripts in init.d. Copy that line to your script then type chkconfig --add {script name}.

 

[IRudebwoy]

Place your script in /etc/init.d/ then use chkconfig -add <filename>. Then issue chkconfig --list <run levels> <filename> on to start it on the appropriate run levels, which places the symbolic links in the correct /etc/rc.d/rc<run level>.d directories.

Make sure your script has a line similar to this near the top of the file or the chkconfig will complain.
# chkconfig: - 91 35

The first number specifies the start order and the last number specifies the shutdown order.

Lorenzo Wacondo (System Administrator)

http://www.laguna-industries.com

## Just because you can do something doesn't mean you should.

 

[GaijinPunch]

Sorry if i didn't give enough info. I've got the link in my rc3.d directory. It is a link to /etc/init.d/nasd (which came packaged with the binary) named S91nasd. The link is definitely right, and I believe the naming structure should be fine as well.

I tried runing chkconfig, but it told me that "add" was not a valid option.

 

[pansophic]

Can you run the service manually by typing

/etc/rc3.d/S91nasd

as root.

If not, it is probably a permissions problem. Who owns the actual binary?


pansophic

 

[GaijinPunch]

Yes, I've been running it manually as it's not starting when the user logs in. It has 755 permissions and is owned by root (like everything else in the directory).

 

[Chacalinc]

could you post the result of [tt]chkconfig --list [/tt]?
what does [tt]nasd[/tt] do? (what is that service)

I've been running it manually as it's not starting [blue]when the user logs in[/blue].

scripts in /etc/init.d (and therefore /etc/rc3.d) start at boot time, and not when a user logs in. If you want a script to run when users login you should add them to the bashrc.

Cheers.

Chacal, Inc.

 

[clonny2]

The reason that chkconfig does not work is that the nasd script is not utilizing chkconfig. You will manually have to add the chkconfig line or you will have to manually create the links in rc.3.

Not hard to do, depending on when in the start order you want nasd to start, just make a link in rc3 from S[X]nasd to init.d/nasd where [X] is a number from 1 to 99.

nasd sounds like a familiar process. What is it?

If you want nasd to start when the user logs in, then do not put it in the rc3 directory. If you add to .bashrc then the script will run everytime you start a new bash process, which is not what you want either. Call the script from .bash_profile instead. Profile gets ran only when you login not everytime a new bash process is invoked.

 

[clonny2]

A good way to test this is to create a script called test.sh which echo "Got here"

In $HOME/.bash_profile add line $HOME/test.sh

Then login and you will get the message "Got Here".

Then try starting another bash process by typing bash and you will not get the message.

Now remove the line from .bash_profile and add it to your .bashrc and try the same steps. You should get the message every time bash starts.

Then just remove the test.sh script and the lines from .bashrc and .bash_profile.

 

[GaijinPunch]

I think that's the problem. When I meant "user logs in" it's b/c he reboots his machine every night, even though I tell him he doesn't have to. nasd is Network Audio Server Daemon, and now that I think about it, starting at boot *might* be the problem, as it needs X11 to play sound. On my gentoo box, I just add it w/ rc-update and it starts fine.

I'm at home now, but will play w/ .bashrc when I get to work.

 

[pansophic]

That might explain it as well. Runlevel 3 is multi-user with networking, but without X. Runlevel 5 is with X. But if the user is using startx to launch X, then you may want to launch from ~/.xinitrc.


pansophic

 

[GaijinPunch]

I use startx on mine. The other users use xdm.

One thing about running it from .bash_profile -- wouldn't it be executed as the user? It needs to be run as root.

 

[Chacalinc]

as pansophic said in his last post, you should put it in the run level 5 in order to start nasd *after* X11.

And yes, scripts run in .bash_profile going to be run as user, not root, that's why you should put it in /etc/rc5.d

Cheers.

Chacal, Inc.

 

[mrballcb]

I'm going to try to tie together a few different posts above to make a clear, concise solution:

Near the top of the nasd init script (but not before the first line) put the following line. The leading # is important:

# chkconfig: 2345 91 35

Then run:

chkconfig --add nasd
chkconfig --list nasd

The second command will fail if the first one fails. The silent success of the first command is good, the second command will print out the runlevels it is set to run in which we manually set to 2, 3, 4, and 5 with the chkconfig setting in the line we added.

Making symlinks in the /etc/rc*.d/ runlevel directories manually should never be required.