0

I am running a Flask application on my RPi successfully by issuing the following command

export FLASK_APP=/opt/fzwk-access-source/app.py && flask run --host 0.0.0.0 

Now, my next goal is naturally to run the Flask application when booting up the RPi. To do so, I created the service /etc/systemd/system/fzwk-access.service, which looks as follows:

[Unit] Description=fzwk-access After=network.target [Service] User=root Group=root Type=forking WorkingDirectory=/opt/fzwk-access-source ExecStart=/bin/bash -c "export FLASK_APP=/opt/fzwk-access-source/app.py && flask run --host 0.0.0.0" [Install] WantedBy=default.target 

ls -la provides me with the following:

... 4 drwxr-xr-x 2 root root 4096 Dec 2 12:41 dhcpcd.service.d 0 lrwxrwxrwx 1 root root 34 Dec 2 12:41 dhcpcd5.service -> /lib/systemd/system/dhcpcd.service 4 -rwxr-xr-x 1 root root 312 Mar 1 17:12 fzwk-access.service 4 drwxr-xr-x 2 root root 4096 Dec 2 12:37 getty.target.wants 4 drwxr-xr-x 2 root root 4096 Dec 2 12:39 [email protected] 4 drwxr-xr-x 2 root root 4096 Dec 2 12:40 halt.target.wants 4 drwxr-xr-x 2 root root 4096 Feb 18 07:38 multi-user.target.wants ... 

With that in place, I can start the service with the command

sudo systemctl start fzwk-access 

successfully. I have thus enabled the service with

sudo systemctl enable fzwk-access 

My expectation now is that after a reboot the service is starting successfully, but it does not.

sudo systemctl status fzwk-access shows the following:

● fzwk-access.service - fzwk-access Loaded: loaded (/etc/systemd/system/fzwk-access.service; enabled; vendor preset: enabled) Active: inactive (dead) 

Clearly, I am missing something here – I cannot figure out what it is...

Update

It turns out that running sudo systemctl start fzwk-access does not work as intended – it will start the Flask server temporarily, but will fail with a timeout (I did not realise that this was happening before because during that startup period of the server, Flask was answering my requests perfectly...). Anyway, it fails with

fzwk-access.service - fzwk-access Loaded: loaded (/etc/systemd/system/fzwk-access.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Mon 2021-03-01 18:58:43 GMT; 4min 36s ago Process: 1170 ExecStart=/bin/bash -c export FLASK_APP=/opt/fzwk-access-source/app.py && flask run --host 0.0.0.0 (code=killed, signal=TERM) ... Mar 01 18:58:43 raspberrypi systemd[1]: fzwk-access.service: Start operation timed out. Terminating. Mar 01 18:58:43 raspberrypi systemd[1]: fzwk-access.service: Control process exited, code=killed, status=15/TERM Mar 01 18:58:43 raspberrypi systemd[1]: fzwk-access.service: Failed with result 'timeout'. Mar 01 18:58:43 raspberrypi systemd[1]: Failed to start fzwk-access. 

journalctl -xe delivers the following:

-- -- The process' exit code is 'killed' and its exit status is 15. Mar 01 18:58:43 raspberrypi systemd[1]: fzwk-access.service: Failed with result 'timeout'. -- Subject: Unit failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- The unit fzwk-access.service has entered the 'failed' state with result 'timeout'. Mar 01 18:58:43 raspberrypi systemd[1]: Failed to start fzwk-access. -- Subject: A start job for unit fzwk-access.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- A start job for unit fzwk-access.service has finished with a failure. -- -- The job identifier is 513 and the job result is failed. Mar 01 18:58:43 raspberrypi sudo[1167]: pam_unix(sudo:session): session closed for user root Mar 01 18:59:03 raspberrypi systemd[1]: Configuration file /etc/systemd/system/fzwk-access.service is marked executable. Please remove executable permission bits. Proceeding anyway. 
2
  • did you read the last line? Commented Mar 2, 2021 at 8:11
  • Yes, I have. I have done chmod 644 fzwk-access.service in the meantime, but that alone had not changed anything. I might have come to a solution, but will have to do some more digging/confirming. Once confirmed, I will put up an answer to help future me and hopefully others... Commented Mar 2, 2021 at 8:34

1 Answer 1

2

Your program is successfully running when started from the command line. So I cannot see a reason why to run it as old style Unix daemon with Type=forking. Then you normally have also to provide the PID of the process so systemd can find the daemon again that it has forked away from its environment. If not needed for backward compatibility of old Unix daemon programs you should use systemds native environment to manage services. It will run them in the background and knows how to access them for management.

And it is also better that systemd provides the environment variable so it can inherit it to sub shells if necessary. And there are default root settings. It doesn't hurt but isn't needed. All together I would try this Unit file:

[Unit] Description=fzwk-access After=network.target [Service] WorkingDirectory=/opt/fzwk-access-source Environment="FLASK_APP=/opt/fzwk-access-source/app.py" ExecStart=/full/path/to/flask run --host 0.0.0.0 [Install] WantedBy=default.target 

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.