This problem has been bugging me for a while, we have a program running on Solaris, which managed as a service well by SMF, can be enabled/disabled very easily.

Now, according to our market, we would like to migrate this service to RHEL 6.3, so we are trying to use Upstart to manage it and make it have the same behaviors like what it does on Solaris. Most of behaviors are good and fulfill our requirements, but when we stop the service, it still was started automatically on startup, this is not what we want. We want to make it be stopped no matter how many times we reboot or shutdown server after stopping the service.

I read this article, Ubuntu12.04: How to disable a daemon process at startup, it says, this feature can be done by Upstart 1.3, but we are limited to use RHEL 6.3, which Upstart package version is 0.6.7, and the most important thing is, no upgrade for Upstart and cannot switch to other platform. :(

So, my question is that: is there any alternative method to achieve my target but not change system and do not introduce any dependencies, and still, this service have to be managed by system, like SMF/Upstart/init.d.

A little more requirement here, we still want to implement a feature that, if user kill the service process, system can detect this and try to start the process automatically with upper limit times, which can be specified as well.

Reference for SMF:

Introducing the Basics of Service Management Facility (SMF) on Oracle Solaris 11 Advanced Administration with the Service Management Facility (SMF) on Oracle Solaris 11

  • Do you want to migrate to RHEL 6 inhouse or for customers? If you say "manage" does SMF integrate upstart or how are you going to do this with upstart? – Nils Sep 30 '13 at 12:00

On rpm based systems like ReHat use chkconfig to configure runlevels. service will handle it on a running system.

To permanently stop a service on RH 6:

service xyz stop
chkconfig xyz off

SMF is much more complex than this. Since it is doing monitoring, restarts and so on it seems to do things that normally are being done by a cluster software.

In a cluster-software, you would classically take the service from the system-control and give to to cluster-control. That service will then start up upon cluster-startup.

There you would have possible commands like:

  • Stop service (once or permanently)
  • Only monitor service
  • Normal cluster-behaviour might restart that service, if monitor returns an unplanned down-state

If you do not want to add a full-cluster-suite you could do a few workarounds:

  • Add a "pstop" method to the init-script that stops the service and touches a planned-downtime-flag
  • write a cron-job that monitors the service and restarts it if down and NOT in planned downtime
  • modify the "start" method of the init-script so it removes the planned-downtime-flag, if it exists
  • Thanks Nils, but it cannot start the process automatically with upper limit like SMF if we use 'service' and 'chkconfig'. Say, with Upstart, when killed the service process, it will try to start the process automatically for 10 times, which is default try time for Upstart. Sorry to say that, I should put this requirement on my question. – Hang Pan Sep 25 '13 at 7:01
  • @HangPan Please do so. It would also great if you could include a link to SMF in your question. – Nils Sep 27 '13 at 9:13
  • Thanks Nils, links added. :) And I added 2 of links which I referred for my project. – Hang Pan Sep 29 '13 at 6:20
  • @HangPan ok - now I see what SMT does. I added some further questions to your original question and added more information to my answer. – Nils Sep 30 '13 at 12:07
  • I do appreciated for your help, I will try this first on my localbox and lab if they persist to use upstart to implement this feature and don't wanna to introduce the 3rd party tool, then talk with our manager and architect. After all, for the first release, we are fine if just leave it alone. Thanks again. :) – Hang Pan Oct 12 '13 at 2:26

If you want to migrate to RHEL, do use RHEL manuals as a reference - reading documentation for Ubuntu's Upstart won't get you far. Init systems are one of the key parts of a Linux distribution that is one of the things that makes a distribution itself. Even though various vendors often strive for some degree of compatibility, reading documentation from other distribution, especially when you moving there from another UNIX system is not a good idea.

RHEL uses upstart in a SysV init compatibility mode and as such it will probably know the service command. By the way, try entering RHEL service management into your favourite search engine - that should give you enough of reasonable reading material.

  • Ya, you're right, peterph, but I just thought maybe it will give me some help for Upstart :) – Hang Pan Sep 25 '13 at 6:59
  • It certainly would, but then RHEL doesn't come with upstart. – peterph Sep 25 '13 at 10:50
  • Right, yesterday, we discussed with our PM and Architect, decide to leave it as it is in the first release, then check if alternative to get this done. Many thanks, peterph. – Hang Pan Sep 26 '13 at 7:23
  • RHEL6 actually uses upstart as init, but doesn't take advantage of any features beyond sysvinit compatibility. RHEL7 will have systemd instead. – mattdm Sep 30 '13 at 13:00
  • Oh, indeed. My bad, sorry @HanPan. – peterph Sep 30 '13 at 19:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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