Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am total Linux n00b entrusted with bunch of PUIAS (RedHat) 6.4 servers and desktops. I noticed after rebooting my computing nodes (done just for testing purposes) that many of the daemons which are started manually after initial installation (ipmi, mcelog, fail2ban) are not running and have to be restarted manually. This server is suppose to run on the run level 3 (no GUI). Similar exercise on the same OS version on the desktops (run level 5) produces totally different outcome. Namely all daemons are properly started.

Is this excepted and should I edit /etc/init.d scripts or maybe just write mine which will start services? Is there the other "correct" way of doing this?

I am coming from OpenBSD world where build in daemons are simply stared by editing /etc/rc.conf.local and all other daemons are started by editing /etc/rc.local.

share|improve this question

1 Answer 1

up vote 2 down vote accepted

(I'm not trying to be pedantic, I just don't know how much you know or don't know, so I'm basically braindumping here)

First off, just be aware that Red Hat picks weird stuff to install and enable by default. For instance it's either RHEL5 or RHEL6 that will install avahi and enable it to start at boot. I think both versions install and enable cups for almost all the installation profiles you can pick. RHEL6 doesn't install man by default, etc, etc.

On RHEL there are three ways you can manage services:

  • Manually modify the symlinks underneath /etc/rc.d or /etc/rcX.d
  • Use chkconfig (modeled after IRIX's tool of the same name)
  • use the setup command provided by the setuptool package (which may or may not be installed depending on the profile that was selected during the initial install).

More details on each:

Manual Management:

The RHEL/System V startup sequence is thus:

  1. /etc/rc.sysinit is ran, which gets most of the critical parts of the operating system such as critical filesystems in place.

  2. init then looks into /etc/rcX.d (where X for the runlevel it's booting into) and executes all the files/symlinks contained therein (in alphabetical order).

    • If their name begins with and S it gives the script start as its argv[1]/$1

    • If their name begins with a K it stops (or kills) the service.

    • Convention has it that dependencies are handled by changing the number after the K or S which has the effect of just changing its alphabetical position.

  3. It executes whatever is in /etc/rc.local


The actual service scripts will be in /etc/rc.d/init.d (which is also symlinked to on /etc/init.d). If you want a service to start at run level 3 (network but no GUI) you could do this:

# cd /etc/rc3.d
# ln -s /etc/init.d/myService S99myService

Using chkconfig

The purpose of chkconfig is basically to automate the above process for you. It has the drawback of requiring that the initscripts have a certain header before you can manage the service with chkconfig. For example, this is the start of the networking service:

#! /bin/bash
#
# network       Bring up/down networking
#
# chkconfig: 2345 10 90
# description: Activates/Deactivates all network interfaces configured to \
#              start at boot time.
#
### BEGIN INIT INFO
# Provides: $network
### END INIT INFO

This enables chkconfig and figure out what number it needs to set/modify in order to get dependencies to work out properly. You lose the ability to change order but because of the above it hardly ever actually matters.

chkconfig is easier and is frankly what I use most of the time.

You can check which services are configured at what run levels via chkconfig --list For example:

[root@ditirlns01 ~]# chkconfig --list | head
NetworkManager  0:off 1:off 2:off  3:off  4:off 5:off  6:off
acpid           0:off 1:off 2:on 3:on   4:on   5:on 6:off
anacron         0:off 1:off 2:on 3:on   4:on   5:on 6:off
arptables_jf    0:off 1:off 2:on 3:on   4:on   5:on 6:off
atd             0:off 1:off 2:off  3:off  4:on 5:on 6:off
auditd          0:off 1:off 2:off  3:off  4:off 5:off  6:off
autofs          0:off 1:off 2:off  3:off  4:on 5:on 6:off
avahi-daemon    0:off 1:off 2:off  3:off  4:on 5:on 6:off
avahi-dnsconfd  0:off 1:off 2:off  3:off  4:off 5:off  6:off
capi            0:off 1:off 2:off  3:off  4:off 5:off  6:off

Or check on the status of particular services:

[root@ditirlns01 ~]# chkconfig --list auditd
auditd          0:off 1:off 2:off  3:off  4:off 5:off  6:off

You can enable a service via chkconfig <serviceName> on Continuing the example above:

[root@ditirlns01 ~]# chkconfig auditd on
[root@ditirlns01 ~]# chkconfig --list auditd
auditd          0:off 1:off 2:on 3:on   4:on   5:on 6:off

As you can see chkconfig enable the auditd service for run levels 3 thru 5.

If you didn't want that you, can use the --levels option to set specific run levels to enable:

[root@ditirlns01 ~]# chkconfig auditd off
[root@ditirlns01 ~]# chkconfig auditd on --levels=3
[root@ditirlns01 ~]# chkconfig --list auditd
auditd          0:off 1:off 2:off  3:on 4:off  5:off   6:off

With setuptool

setup is the latest iteration of system management, designed to make common administrative tasks a little easier. It would work that way if Red Hat would install everything needed to make it so. But starting with RHEL6 they separated out setuptool functionality amongst several packages (I guess to make it more comprehensive without clogging the menu).

It's a pretty self-explanatory ncurses-based wrapper around chkconfig except that it doesn't let you single out particular run levels:

Initial screen

Actual Management Screen

Not much to say about it beyond that.

Let me know if that answered you question.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.