I'm in the process of learning Upstart after first having learned SMF.

Naturally I'm assuming that they fulfill the same purpose but I'm aware that this is where I'm wrong.

Ideally I was hoping that someone had written a comparison so that I wouldn't have to dig for features in Upstart that just isn't there. Solaris has something called the Contract Subsystem which is build into the kernel and this is actually what enables most of the features in SMF. I'm aware that there's potentially no equivalent in Linux and this may be the reason why I cannot figure out what I can expect from Upstart in terms of service stop and also on service monitoring and restart-on-failure.

To be more specific about the things I cannot truly figure out in Upstart:

  1. Stopping. With SMF I'm pretty much used to letting SMF do the stop process. I never really write specific kill scripts, I do not have to keep track of PIDs and I do not need to know how many times a process spawns, etc. This seems more of a DIY process in Upstart. Correct ?

  2. Restart-on-failure. I don't really understand if this is a feature of Upstart or not. I see Linux people coupling Upstart with some type of userland process monitoring mechanism. Perhaps that is what I should be doing?

  3. Viewing. I'm fond of the SMF svcs -p <servicename> command which allows me to see all the processes that are (currently) part of the service. In Upstart it seems to me that "a service " = "a process" meaning that in Upstart the initctl status <jobname> command will always only show a single process. What if I have a service that from the OS's point of view is two separate processes ?

  4. Guaranteed-only-one-instance. For most daemons you really want to make sure that there's only ever one started instance. For some services even an attempt to start a second instance may be fatal. I would like to tell Upstart this and have Upstart guarantee me this. So, even if the operator executes service xyz start and xyz is already running it shouldn't cause an attempt to start another instance of xyz nor should it cause an attempt to restart xyz. Can I do that?

  5. Delegation. With SMF I delegate responsibility to certain services to non-privileged users. For example I have a small group of non-privileged users who has been granted the right to start/stop their own port-80 webserver. I do this by assigning the right to this service to be able to bind to a privileged port (portno<1024) without assigning any other root-like privilege to the service. Then I delegate the start/stop privilege on that service to a group of users, through a role. I'm assuming that in Upstart I would have to do some sudo scripting to achieve the same ?

When looking more closely at it seems to me that Upstart is almost intended even as a replacement for cron. It has the concept of short-running jobs or repeated tasks which SMF doesn't. SMF is - as the name suggests - purely focused on services, i.e. long-running processes. This may be what confuses me. But right now I'm only focused on how to configure those long-running processes. I'm looking for a way to describe my service to the OS (e.g preconditions, how to start, stop, delegation, privileges, etc) and then have the OS take care of it from thereon.

UPDATE 1: Learned some more: This is for sure not unified across Linux, i.e. there's no consensus in Linux community over this matter ... to put it mildly. This means that I have to let you guys know the distro: CentOS and sometimes a bit of RedHat (both in version 6 series).

UPDATE 2: I've found that - at least some people say - that RedHat (and thus CentOS) will in next major release be ditching Upstart in favor of something called systemd. This just leaves me even more confused. What to do if I want to build reliable services on CentOS/RH today?



Browse other questions tagged .