Running Python Script as a Systemd Service

systemd service activation for Python script fails

Related posts brought me to the resolution for my issue. Ubuntu systemd custom service failing with python script refers to the same issue. The proposed solution adding the WorkingDirectory to the Service section resolved the issue for me. Though, I could not find the adequate systemd documentation outlining on the implicit dependency.

Running Python script as systemd service, connecting to InfluxDB results in ConnectionError

You may still run into a problem even if you create the service dependency (because it's possible that influxdb takes a moment before it is ready to accept connections, during which time the Python code might start). The solution is to either:

write your Python code to retry connections when they are refused or
configure systemd to restart your service if it fails.

Without seeing your Python code it's hard to suggest what the first solution might look like, but configuring your unit to restart on failure is as simple as adding the following to your [Service] section:

Restart=on-failure

You can delay startup of your Python code until influxdb is ready by adding a small shell script to your systemd unit:

ExecStartPre=/bin/sh -c 'while ! curl -sf http://localhost:8086/ping; do sleep 1; done'

This will loop indefinitely (thus preventing the service from starting) until influxdb is responding successfully to the /ping endpoint.

Systemd says my service is active and started, but I receive no output

Try using /usr/bin/python3 -u and then the file path.

The -u option tells Python not to fully buffer output.

By default, Python uses line buffering if the output is a console, otherwise full buffering. Line buffering means output is saved up until there's a complete line, and then flushed. Full buffering can buffer many lines at a time. And the systemd journal is probably not detected as a console.

How to make a Python script run like a service or daemon in Linux

You have two options here.

Make a proper cron job that calls your script. Cron is a common name for a GNU/Linux daemon that periodically launches scripts according to a schedule you set. You add your script into a crontab or place a symlink to it into a special directory and the daemon handles the job of launching it in the background. You can read more at Wikipedia. There is a variety of different cron daemons, but your GNU/Linux system should have it already installed.
Use some kind of python approach (a library, for example) for your script to be able to daemonize itself. Yes, it will require a simple event loop (where your events are timer triggering, possibly, provided by sleep function).

I wouldn't recommend you to choose 2., because you would be, in fact, repeating cron functionality. The Linux system paradigm is to let multiple simple tools interact and solve your problems. Unless there are additional reasons why you should make a daemon (in addition to trigger periodically), choose the other approach.

Also, if you use daemonize with a loop and a crash happens, no one will check the mail after that (as pointed out by Ivan Nevostruev in comments to this answer). While if the script is added as a cron job, it will just trigger again.

python program slower running as a systemd than running it from terminal

It is entirely possible that scripts running as systemd service may be slower than directly from Terminal - likely due to different resource allocations. For instance, I would expect scripts ran from Terminal (i.e. explicitly by the user) to receive a higher priority and therefore greater amount of resources in contrast to background processing.

You can, however, assign more resources including CPU and RAM to your service using systemd.resource-control.

For example, you could try increasing CPUWeight from the default value of 100 to 1,000.

[Service]
CPUWeight = 1000

Adjusting other parameters may finally lead to your desired execution time. Do keep in mind that providing a greater amount of resources to your service it may impact the performance of your overall system.