{"id":41,"date":"2008-01-26T13:18:24","date_gmt":"2008-01-26T18:18:24","guid":{"rendered":"http:\/\/yourlinuxguy.com\/?p=41"},"modified":"2008-03-14T08:54:09","modified_gmt":"2008-03-14T13:54:09","slug":"how-do-i-specify-service-start-order-in-suse","status":"publish","type":"post","link":"https:\/\/yourLinuxGuy.com\/?p=41","title":{"rendered":"How do I specify service start-order in Suse?"},"content":{"rendered":"

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…<\/em><\/font><\/p>\n

You don’t. \ud83d\ude09 Just kidding… *kinda*…<\/p>\n

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

“Ah-hah!”, you say, because you are an old-school Unix guy (yes, Your Linux Guy knows about you and your ways \ud83d\ude09 ), 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<\/code> directory, right? Wrong. Well, you *could* do that, but as soon as you run chkconfig<\/code> on Suse, it will re-order your service based on some other criteria… more on that in a moment.<\/p>\n

First some background on RedHat…<\/p>\n

Many of you are used to the tool chkconfig<\/code>. 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<\/code> directory:<\/p>\n

# chkconfig: 35 98 01<\/code><\/p>\n

…note that the leading pound\/hash symbol indicates that it is a comment; this is important. Then, after the chkconfig:<\/code>, 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<\/code> after your modifications for it to take effect; it goes through and reads all those comments and places things in the appropriate place.<\/p>\n

Now, on to the Suse insserv<\/code> method…<\/p>\n

Suse uses a similar philosophy to RedHat’s chkconfig<\/code> with insserv<\/code> 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<\/code> you were hoping for.<\/p>\n

So, specifically, here is an example comment block with just a reasonable minimum, for a fake application called myapp<\/code>:<\/p>\n

### BEGIN INIT INFO
\n# Provides: myapp
\n# Required-Start: $ALL
\n# Default-Start: 3 5
\n# Default-Stop: 0 1 2 4 6
\n# Description: My App is cool
\n# Short-Description: My App
\n### END INIT INFO<\/code><\/p>\n

…this example will cause myapp<\/code> to be one of the last things loaded (the $ALL<\/code> is a special value, see below), in runlevel<\/code> 3 or 5, and will stop at all other levels. On my machine, it puts myapp<\/code> at S21<\/code>, right before S21SuSEfirewall2_setup<\/code>, which is numerically equal, but alphabetically later. And — just like with RedHat — you must run chkconfig<\/code> or the Suse tool insserv<\/code> for the scripts to be re-arranged and placed, ready to run. Its important to remember that on Suse, chkconfig<\/code> is just a child to insserv<\/code>, 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.<\/p>\n

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

# Required-Start: $sshd<\/code><\/p>\n

…and then myapp<\/code> would have been placed to start right after sshd<\/code> in the appropriate \/etc\/init.d\/rc[?].d<\/code> directory. On my machine, sshd<\/code> is at S12<\/code>… so if I did that, myapp<\/code> would likely be at S13<\/code> (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:<\/code>” line. Also, the $ALL<\/code> is a special all-inclusive facility value that means “all facilities”, and when used, it causes your script to be loaded after all others.<\/p>\n

Warning: Some of the startup scripts in Suse have the RedHat chkconfig<\/code> 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<\/code> binary (which works on Suse to a lesser extent than on RedHat) for your convenience… and confusion…<\/p>\n

Phew! Got it? Good.<\/p>\n

Make sure to let me know if I missed something…<\/p>\n

\ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"

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…
Read more<\/a><\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[12,25,15],"tags":[],"class_list":["post-41","post","type-post","status-publish","format-standard","hentry","category-advanced","category-redhat","category-suse"],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pnjn1-F","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/yourLinuxGuy.com\/index.php?rest_route=\/wp\/v2\/posts\/41","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/yourLinuxGuy.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/yourLinuxGuy.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/yourLinuxGuy.com\/index.php?rest_route=\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/yourLinuxGuy.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=41"}],"version-history":[{"count":1,"href":"https:\/\/yourLinuxGuy.com\/index.php?rest_route=\/wp\/v2\/posts\/41\/revisions"}],"predecessor-version":[{"id":310,"href":"https:\/\/yourLinuxGuy.com\/index.php?rest_route=\/wp\/v2\/posts\/41\/revisions\/310"}],"wp:attachment":[{"href":"https:\/\/yourLinuxGuy.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=41"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/yourLinuxGuy.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=41"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/yourLinuxGuy.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=41"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}