2

I've been looking up information on running background processes on Linux. The basic requirements are:

  • Start the process and keep it running no matter what happens
  • If the process quits for whatever reason, immediately relaunch it
  • Be able to launch the process as a specific user

Additionally, some processes need to be run not continuously, but periodically. This is of course a job for cron, and more than likely it's what I'll use for that. But for continuous processes, it's a different story.

On Mac OS X, I use launchd for this purpose. Launchd is the canonical method for launching processes on Mac OS X. The operating system uses it for ALL system services, so I have no qualms about relying on it. So far I haven't found a similar system for Linux. Various distros all seem to have their own methods (Ubuntu's upstart, etc.) and I still can't find a straight answer on how /etc/rc.local, /etc/init.d/rc.local, /etc/initd/rc.local, or /etc/init all relate and what the difference is between them. They're different on every system. Add to that the fact that "service start/stop x" doesn't work on all systems (and Google hasn't helped here) and you have what I'd call a mess.

What I want is ONE place I can save my scripts where I can reboot the system and have them launched as daemons at boot (before any user logs in), then have them automatically restarted if they ever terminate. And I want it to be rock solid reliable and fully compatible with multiple distros, not some afterthought like upstart.

Is this even possible?

  • 2
    I don't really agree with the starting assumptions. "keep it running no matter what happens" is not a characteristic of daemons, which at its simplest refers to a process not associated with a controlling terminal. Beyond this basic tenant, you have a choice of frameworks for managing your daemons, which may or may not include a feature for supervision/respawning. Use the tools that best suit the software you're running. It would be a really bad idea for certain daemons to automatically respawn when they die... – Andrew B Nov 16 '13 at 6:49
  • Welcome to the world of Linux Distributions where everything is the same but different. You may want to consider supervisord.org – user9517 Nov 16 '13 at 8:20
  • "Start the process and keep it running no matter what happens" So you're saying that if the administrator does something like /etc/init.d/yourdaemon stop then the daemon should automatically restart without any intervention of the administrator? – a CVn Nov 16 '13 at 13:42
  • Is this for software you distribute, or just software on your own system? – sciurus Nov 16 '13 at 14:15
  • @AndrewB - I agree, some shouldn't, but for certain ones the option is good. In the rare event that something does quit, I'd like to have the reassurance that it'll restart. – Justin Mrkva Nov 16 '13 at 16:02
6

Sorry, the Linux distributions (in their infinite quest to differentiate themselves and make life difficult for system administrators) have each standardized on doing the startup thing differently.

The closest thing to a "cross-distribution standard" for Linux startup scripts would be the System V style runlevels. These are deprecated on some systems (for example Ubuntu's official position is you should use Upstart), but they still work and probably will for a good long while.

SysV init scripts do not handle "automatically restarting" if your daemon crashes - they launch a daemon which is expected to take care of itself.
If you want supervision you would need to write/include your own supervisor framework.
(Alternatively simply write a decent piece of software that doesn't crash, which is the traditional Unix way of dealing with this. If your daemon is so unstable that it needs extra supervision to keep restarting it that usually means you need to do more work on making it production-quality.)

3

You were close with upstart - what you need is systemd. It is not fully supported yet, but handles old-style SysV init scripts (though without supervision) and can be easily adopted to run on many distros. There is no better solution available for now out of the box, but if you prefer not to change entire init you might be interested in monit daemon, which can be easily instructed to supervise almost any service.

  • You may wish to review this blog post; while it's mostly aimed at product recommendation questions, some of the advice also carries over to product recommendation answers. (they don't stand up well on their own) – Andrew B Nov 16 '13 at 8:45
  • No, this was not a shopping problem - at the time of writing this upstart was already "obsoleting" and entire community drifted into systemd. By "community" I mean system administrators, developers and distro maintainers, who are very close to init scripts, not the lusers that have no idea about underlying problems with service supervision. Now, 4.5 years later, there is no alternative to systemd (unless doing some hand-crafted scripts for embedded stuff). – Tomasz Pala Jun 6 '18 at 8:47
  • As fun as it would be to debate semantics, this is a four year old answer and a four year old comment. – Andrew B Jun 7 '18 at 3:17
1

What I want is ONE place I can save my scripts where I can reboot the system and have them launched as daemons at boot (before any user logs in), then have them automatically restarted if they ever terminate. And I want it to be rock solid reliable and fully compatible with multiple distros, not some afterthought like upstart.

This doesn't exist. Even if you limit yourself to the enterprise linux distributions, you'll find a variety of init systems, e.g.

  • SysVInit: Red Hat Enterprise Linux 5, SUSE Linux Enterprise 11
  • Upstart: Red Hat Enterprise Linux 6
  • Systemd: Red Hat Enterprise Linux 7, SUSE Linux Enterprise 12

The most "compatible" way is to write sysvinit scripts, since both upstart and systemd support them. However, it doesn't support automatically restarting services if they die. Both upstart and systemd do support that.

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.