0

I'm not sure what the general methodology of daemonizing a script is. For example, I've searched online and if I was trying to write a python script that checked the time every second on my computer, all I could think of is using systemd to start it up and then in Python write the script within a never ending loop with a timer.

This neither make much sense to me nor does it seem like a good way of daemonizing. All I would do with systemd is use it to run the script (and any script) at startup, so systemd itself doesn't seem very useful. I think I may be daemonizing my script wrong, so do you know what the better ways are to use systemd to turn a python script into a daemon process?

Thanks

closed as too broad by Stephen Rauch, roaima, Thushi, Archemar, user34720 Jul 10 '17 at 19:55

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

4

systemd is not a catch-all. It won't be the solution to every problem, however it does give you a lot of tools to help you solve problems. The usefulness of those tools comes down to how well you can use them.

Let's look at a very basic service file check-time.service (note that I created this service file by hand, using other service files located in /usr/lib/systemd/system/ as references):

[Unit]
Description=Checks the time every second

[Service]
Type=simple
ExecStart=/usr/bin/check-time.py

The service file belongs in /usr/lib/systemd/system/ or /etc/systemd/system/ to be used by systemd


Line By Line

[*] The section headers. These just group together directives. You can find references to which directives belong where in the systemd man pages:

[Unit] section

[Service] section

[Install] section

Description

A free-form string describing the unit. This is intended for use in UIs to show descriptive information along with the unit name. The description should contain a name that means something to the end user. "Apache2 Web Server" is a good example. Bad examples are "high-performance light-weight HTTP server" (too generic) or "Apache2" (too specific and meaningless for people who do not know Apache).

type

Configures the process start-up type for this service unit. One of simple, forking, oneshot, dbus, notify or idle.

If set to simple (the default if neither Type= nor BusName=, but ExecStart= are specified), it is expected that the process configured with ExecStart= is the main process of the service. In this mode, if the process offers functionality to other processes on the system, its communication channels should be installed before the daemon is started up (e.g. sockets set up by systemd, via socket activation), as systemd will immediately proceed starting follow-up units.

ExecStart

Commands with their arguments that are executed when this service is started. The value is split into zero or more command lines according to the rules described below (see section "Command Lines" below).


Summary

This service file would simply run the command /usr/bin/check-time.py when started. If the command exits then it would be considered "dead", so long as it continues to run it is considered "Active".

How useful is this service file? Well, not very. As it is the only thing it does is allow you to run the python script using systemctl start check-time.service instead of the normal full path, however there are a wealth of additional options that can be useful.


Useful Options

WantedBy If you want the service to start on boot, set WantedBy= your default target.

Restart Determines when systemd should automatically restart a service, such as "always" or "on-failure"

Literally hundreds of other options that include limiting hardware usage, which user to use to execute the process, setting environment variables, setting dependencies, and many more. systemd is useful for all the additional functionality it provides, not simply because it can wrap things.

  • I just want to confirm, the basic process for creating a daemon is write an init script using something like systemd to startup the script, and embedding an infinite loop inside of the script right? – Goldname Jul 10 '17 at 15:24
  • An infinite loop is not required. RemainAfterExit= can consider a service to be "Active" even if the ExecStart exits. systemd can handle all kinds of different executables. – Centimane Jul 10 '17 at 15:50
  • So what exactly happens if it considers a service to be Active? What does it do to the service – Goldname Jul 10 '17 at 19:38
  • Nothing, "Active" means everything is going well, so systemd should let it be (aside from resource limiting directives). systemd is useful for modifying how and when things launch, but if they're launched and running fine it will leave them be generally. – Centimane Jul 10 '17 at 21:02
  • And if its Dead it does nothing as well? Then what's the difference? – Goldname Jul 10 '17 at 22:26
0

Not sure what you asking about. Systemd is init system, so it's job is to run processes at startup.

Edit: To list services in system run:

systemctl list-units --type service
  • but it's job is to daemonize something right? – Goldname Jul 10 '17 at 14:01
  • Of course. The are plenty of system services which are run at startup by systemd. Check this RedHat documentation Managing System Services . It depends on you what you want to run, for example you can write you own server in python and run it at startup with systemd – mrc02_kr Jul 10 '17 at 14:06

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