Service does not start at boot time

Question

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.

Answer 1

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