Is there any commands/scripts to write to automatically to restart a process (after identifying prosess ID)when it crashes or killed.

example , i am running a executable bin file and wanted to restart automatically every time when it crashes or get killed.

  • 4
    use systemd, this is one of its goals. Jan 11, 2017 at 5:20

2 Answers 2


To expand on Ipor Sircer's comment about using systemd

From the RHEL 7 Documentation:

Systemd is a system and service manager for Linux operating systems. It is designed to be backwards compatible with SysV init scripts, and provides a number of features such as parallel startup of system services at boot time, on-demand activation of daemons, support for system state snapshots, or dependency-based service control logic. In Red Hat Enterprise Linux 7, systemd replaces Upstart as the default init system.

Basically systemd manages services and the system as a whole. If you want a process to always be running, then you want it to behave as a service. It is not difficult to make custom service files.

Service Files belong in /etc/systemd/system/NAME.service as per documentation

An example of a custom service file from the RHEL 7 documentation again:




Their description of what this file does:


service_description is an informative description that is displayed in journal log files and in the output of the systemctl status command.

the After setting ensures that the service is started only after the network is running. Add a space-separated list of other relevant services or targets.

path_to_executable stands for the path to the actual service executable.


WantedBy states the target or targets that the service should be started under. Think of these targets as of a replacement of the older concept of runlevels, see Section 9.3, “Working with systemd Targets” for details.

Type=simple is the norm, and assumes the executable launched in the ExecStart will remain running.

Back to the original question, if you use systemd to turn your process into a service you can use systemd to ensure your service is always running.

From the RHEL 7 Documentation again:

Another example is a configuration file that restarts the service after its main process exited, with a delay of 30 seconds:


If you just add the Restart=always option into the [Service] section of your service file the service should restart any time it goes down/exits unless you stop it using systemd.


Dan Bernstein's daemontools was designed to do this and began a whole family of toolsets that share the same raw mechanisms:

Under pretty much any of them, one writes a run program that runs/is the dæmon, and a service manager or supervisor process simply monitors it as a forked child process using the normal Unix and Linux mechanisms. This can be done either system-wide with a dedicated service manager run as the superuser, or per-user with individual service managers.

All of these toolsets are coherent and self-consistent, but note that none of them demand that one use any of the tools other than the ones needed in any particular situation. One can also mix and match. One can use Laurent Bercot's execlineb and all of its utilities under perp, or my nosh script interpreter and all of its utilities under runit; just as one can equally use Gerrit Pape's chpst under my service-manager.

Equally, you could employ a systemd-wide or per-user service run from systemd. systemd unit files are on the same order of simplicity as run scripts, albeit that being non-imperative they do not provide the fine-grained exact control over how the service process's execution state is set up. It is, of course, 2017 and the first rule for migrating to systemd applies.

All of these provide the basic substrate of starting a dæmon at bootstrap, stopping and starting it under administrator/automated control whilst the system is running, and automatically restarting it in various failure cases.

Further reading

  • Just a note about processes, daemons and services. If the process is a daemon providing a service, then the service may be kept alive though systemd or other similar frameworks. If the question is about "any process", then it is a bit too broad.
    – Kusalananda
    Jan 11, 2017 at 12:19
  • For older Linux/Unix systems, inittab and respawn is a pretty good solution Nov 27, 2019 at 15:59
  • For older Unix systems, the system that superseded inittab in 1988 (the Service Access Facility) is pretty good. /etc/ìnittab however, is not. There are good reasons that it was superseded by the SAF. For older Linux systems, some of the softwares mentioned in the answer have been around since the 1990s, and several will work on older Linux systems.
    – JdeBP
    Dec 18, 2019 at 12:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .