raspberry pi - systemd service not starting on boot, starts when i restart it

Question

I have made this service file to start a python script when my raspberry pi (4) boots up:

/etc/systemd/system/plants.service

[Unit]                                    
Description=plant-sender                                    
After=network.target                                    

[Service]
Type=simple                                    
User=root                                    
Group=root                                    
WorkingDirectory=/home/theo/Repos/plants-monitor/remote                                    
ExecStart=/usr/bin/python main.py                                    
Restart=on-failure                                    

[Install]                                    
WantedBy=multi-user.target

However, once the pi is on, I run sudo systemctl status plants, and get:

* plants.service - plant-sender
     Loaded: loaded (/etc/systemd/system/plants.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Mon 2020-03-30 20:22:43 EDT; 1min 45s ago
    Process: 323 ExecStart=/usr/bin/python main.py (code=exited, status=1/FAILURE)
   Main PID: 323 (code=exited, status=1/FAILURE)

Mar 30 20:22:43 arpi systemd[1]: plants.service: Scheduled restart job, restart counter is at 5.
Mar 30 20:22:43 arpi systemd[1]: Stopped plant-sender.
Mar 30 20:22:43 arpi systemd[1]: plants.service: Start request repeated too quickly.
Mar 30 20:22:43 arpi systemd[1]: plants.service: Failed with result 'exit-code'.
Mar 30 20:22:43 arpi systemd[1]: Failed to start plant-sender.

But, after running sudo systemctl restart plants, the service starts up and everything is fine.

Answer 1

If it doesn't start on boot but does on systemctl restart, I'd be looking at whether /home/theo/Repos/plants-monitor/remote is mounted at that point.

There may be something automounting or home-mounting your home directory when you log in.

If so, you could change the working directory to something that exists always, even if only a test.

Additionally, using journalctl -n 9999 -u plants will get you more log messages, so you can see why it's failing, rather than just seeing the "tried too many times, giving up" messages.