How do I specify service start-order in Suse?

This item inspired by Ken. And in order to keep this answer relatively short, I have to skip a bunch of pre-reqs. I’m going to assume that you understand service startup and run-levels in Linux, and maybe have tried specifying start-order in RedHat… This is where my thinking went when answering the question for Ken, so that’s what you get here. Anyway, back to the question at hand…

You don’t. 😉 Just kidding… *kinda*…

So you already know how to cause services to start and stop at various runlevels using the chkconfig tool on RedHat (and the RedHat derivatives, which I just refer to as RedHat) and Suse, or the insserv tool on Suse. But *now* what you want to do is enforce the service load sequence by number.

“Ah-hah!”, you say, because you are an old-school Unix guy (yes, Your Linux Guy knows about you and your ways 😉 ), and you know that all you have to do is hand-write a script, and throw it (or a symlink) into the appropriate rc[?].d directory, right? Wrong. Well, you *could* do that, but as soon as you run chkconfig on Suse, it will re-order your service based on some other criteria… more on that in a moment.

First some background on RedHat…

Many of you are used to the tool chkconfig. In order to specify load order in RedHat, you make sure that one important line similar to the following exists in the start script in the /etc/rc.d/init.d directory:

# chkconfig: 35 98 01

…note that the leading pound/hash symbol indicates that it is a comment; this is important. Then, after the chkconfig:, the next items are as follows: runlevels in which to start (3 and 5), start sequence number (98, which is very late in the order), and stop/kill sequence number (01). Yours, of course, will vary. And — very important here, folks — you need to run chkconfig after your modifications for it to take effect; it goes through and reads all those comments and places things in the appropriate place.

Now, on to the Suse insserv method…

Suse uses a similar philosophy to RedHat’s chkconfig with insserv only insofar as there are a certain set of comments in the start script required to enforce start order. However, instead of you having the luxury of being able to specify *the exact number* for the startup script, you only get to specify things that should be started *before* or *after* your script. This will effectively do the same thing with the arrangement, though you might not get the pretty number S98 you were hoping for.

So, specifically, here is an example comment block with just a reasonable minimum, for a fake application called myapp:

# Provides: myapp
# Required-Start: $ALL
# Default-Start: 3 5
# Default-Stop: 0 1 2 4 6
# Description: My App is cool
# Short-Description: My App

…this example will cause myapp to be one of the last things loaded (the $ALL is a special value, see below), in runlevel 3 or 5, and will stop at all other levels. On my machine, it puts myapp at S21, right before S21SuSEfirewall2_setup, which is numerically equal, but alphabetically later. And — just like with RedHat — you must run chkconfig or the Suse tool insserv for the scripts to be re-arranged and placed, ready to run. Its important to remember that on Suse, chkconfig is just a child to insserv, it is not the same exact tool as on RedHat. But like on RedHat, it will parse the comments fields and place the script in the appropriate places.

Now here’s how that actually works on Suse…
For Suse, the “Provides:” item in the script creates something called a “facility”. So in my example above, I’ve created a facility called “myapp“. Then, others scripts can reference that facility in specifying whether they should load before or after. For example, the sshd startup script provides a “sshd” facility (it does not have to be the same name as the daemon), so I could have put the following in my myapp script:

# Required-Start: $sshd

…and then myapp would have been placed to start right after sshd in the appropriate /etc/init.d/rc[?].d directory. On my machine, sshd is at S12… so if I did that, myapp would likely be at S13 (the next higher number). Note that the facility is prefixed by a dollar-sign when it referenced/called, but not when it is created in the “Provides:” line. Also, the $ALL is a special all-inclusive facility value that means “all facilities”, and when used, it causes your script to be loaded after all others.

Warning: Some of the startup scripts in Suse have the RedHat chkconfig syntax in them. Why? To mess with you. No, not really, but that’s what it did to me when I was first figuring this stuff out. Especially since Suse has the chkconfig binary (which works on Suse to a lesser extent than on RedHat) for your convenience… and confusion…

Phew! Got it? Good.

Make sure to let me know if I missed something…



  1. poohlo

    Thanks! it’s really usefull!

  2. daedlus

    I was actually mislead by other article where it said chkconfig > insserv on suse

  3. Jeremy Pavlov


    Well, depending on what you mean by “chkconfig > insserv”, I don’t necessarily disagree. To quote myself from, above, “…Its important to remember that on Suse, chkconfig is just a child to insserv….”

    Do a “chkconfig -h” on a Suse box and see that, in some cases, it shows that it will effectively run a correlating “insserv” command.

    Here’s an example from the help:
    “chkconfig -d|–del [names] (runs insserv -r)”

    I hope that clarifies…

  4. Bilal


    I am using # Required-Start: $ALL but my daemon process starts before the cron daemon on OpenSUSE. I want to make my daemon process run after the cron daemon has been started

  5. Jeremy Pavlov

    @ Bilal

    A couple thoughts:

    Note that when you look at the cron start script, it “Provides: cron”. This means you can mention that “facility” by name in your other daemon script like this:
    # Required-Start: cron
    …and that will make your daemon script numerically higher than cron.

    But the “$ALL” magic facility should work anyway… It should make your daemon one of the numerically highest ordered scripts.

    However, make sure you’re running chkconfig after editing your file, so it can inspect the instruction and re-arrange the order for you, like this:
    chkconfig mydaemon off
    chkconfig mydaemon on

    I hope that helps!

  6. Bilal

    Many thanks Jeremy. The following has solved my problem.

    # Required-Start: cron $ALL

  7. dsf

    So to clarify, the following line:
    # chkconfig: 35 98 01

    is not really necessary in my start up script for SuSE?

  8. Jeremy Pavlov

    @dsf –
    Whoa! This is a 6-year-old post. You are correct, but I have to admit I haven’t checked in a while…
    The bottom line is that chkconfig uses those numbers (even if you run it on Suse), and innsrv does not. So you don’t *need* those numbers on Suse.
    …and I *think* it has not changed in the last 6 years…

  9. Axel Werner

    That # chkconfig: 35 98 01 remark on start/stop Scripts does not always work on SuSE Linux Enterprise (SLES 11) it seems. yesterday i was fighting a pre-made start/stop script of jetty on our sles 11 sp3 linux server. it had that “chkconfig” tags in there and was supposed to be used with ” chkconfig -a” to have it added to the run levels. – it worked HALF WAY and not the way it was defined within the “chkconfig tag”. In YOUR Example up there a service is supposed to be started on Runlevels 3 and 5, BUT on starting possition 98 and killing possition 03 . Im out Server this portion is totally ignored and the start/stop script was ALWAYS be inserted at Start+Kill Position 01 which was WAY TO EARLY in the start process. i searched the whole web and tried every configuration example i found for chkconfig without luck. would love to know WHY this does not work on SLES11 :/ to get things up running we then added the newer “insserv” Info Tags there . THAT somehow was correctly handeled by the chkconfig command line tool and the service was inserted at a better (later) starting point. And Ideas?

Leave a Comment

Your email address will not be published. Required fields are marked *