3

I have been implementing various services in python for a Linux based embedded system. There is one driver service that needs to run forever as soon as the system boots. It spawns the other services as a child process in a timely fashion and keeps on looping this part. The major goal which I want to achieve is that this driver service should never stop unless the system is shutdown. I have the following options to do so:

  • To make this service as a system daemon and let it run continuously
  • To start this service as a normal process and let it run continuously

which option should I take and why? Also, What is the fundamental difference between both approaches?

Rahul Gusai
  • 133
  • 2
    You need to tell us more about what the service does in order for us to answer your question. Also, as an aside, there is no advantage to speak of. – schaiba Nov 29 '19 at 10:12
  • A daemon is a "normal process". There is no difference between your two alternatives. Could you specify more carefully how you distinguish a daemon from any other process that provides a service? – Kusalananda Nov 29 '19 at 10:17
  • See also JdeBP’s page on the topic. – Stephen Kitt Nov 29 '19 at 10:28
  • @Kusalananda Okay, so you are saying that there will be no advantage or disadvantage for either of the two alternatives ? – Rahul Gusai Nov 29 '19 at 10:59
  • I have edited the question for a better clarification. – Rahul Gusai Nov 29 '19 at 11:00
  • It is still unclear what you mean by "system daemon". Can you clarify what you mean by that, in respect to the other option? Do you mean that the first is launched by a user-space system management such SystemD or supervisord? – Guss Dec 02 '19 at 10:01
  • @Guss Yes you can say that, by system daemon, I meant that the process is not tied to any controlling terminal and it's parent is init process. – Rahul Gusai Dec 02 '19 at 18:16

1 Answers1

3

I'll address the question title first: the difference between a daemon and a normal running process is that most times when you say "normal process" you mean something that is connected to a user input/output API, such as a text terminal (usually by having its first 3 file descriptors in the file descriptor table opened and connected to a virtual terminal of some sort), or a graphic user interface (on Linux and UNIX usually using the X11 protocol). A daemon on the other hand often refers to a process that has been detached from a terminal, or was never attached to one in the first place.

As to the question itself, both when running as a daemon, or when running as a "normal process", an application might crash and will need to be restarted. When the process is connected to some user terminal, a user can detect the fault and restart the application, but a daemon usually doesn't enjoy that feature - when the daemon disconnects from a terminal, it makes it much more difficult to detect that the process has crashed.

To solve this problem, we invented service management frameworks. There are many different implementations, with different features: SysV, SystemD, Upstart, Supervisord, runit, and many others. They all share a very important feature: they have some way to start a daemon (often automatically on boot) monitor it until it fails, and then start it again.

Should you use a service management framework to run your device driver service? You most definitely should - it is the only sane way.

Which service management software to use, is a more difficult question. Usually, the best choice is to use whatever service management software your operating system bundles - usually this software is also running as process ID 0 and started directly by the kernel. Currently, the most prominent such software in modern Linux based operating systems is SystemD which offers a lot of features such as rich dependency management language, socket activation, timers, network and storage management and more. AFAIK, in embedded Linux operating systems this is not often the case and likely your embedded system uses classic SysV which isn't very good at restarting failed services (or often doesn't do that at all - it leaves that task to the "service script" and most implementations do not perform any kind of restart). With a SysV based operating systems, a lot of administrators prefer to use the SysV service framework to just start another service manager - such as supervisord or runit - and let that manage their services.

Guss
  • 12,628
  • Os has systemd and start-stop-daemon services available. You said that the only sane way is to use service management service but there is no specific advantage of using either of the two options(normal process and Daemon), right? – Rahul Gusai Dec 03 '19 at 20:52
  • start-stop-daemon is not a service manager. It's a utility that can be used to construct service management tools and it's often used by SysV service scripts. In order to use it to perform automatic recovery in case of failure, you have to do a lot of heavy lifting yourself. If you have SystemD - use it. It is a great tool with lots of features and really easy configuration. – Guss Dec 03 '19 at 22:07