My user service which is a python script does not run on boot. It runs on raspbian OS as user pi. As most of these questions go I can start the service and it runs fine with systemctl --user start argus but it does not start on a reboot.

Description=RAL Argus Service

ExecStart=/usr/bin/python3 /home/pi/RAL/Argus/Hextapus_Base.py -bsi=5 -pupd=59 -bm=1


I have run sudo loginctl --linger $USER so the service should run even if pi user is not logged in.

The script runs collects data from sensors and shutdowns the device (issues sudo shutdown now) when it is finished collecting data. A RTC wakes up the system again and the scripts runs and repeats the process all over again.

On boot here is the output of systemctl --user status argus

pi@raspberrypi:~ $ systemctl --user status argus
â—� argus.service - RAL Argus Service
   Loaded: loaded (/home/pi/.config/systemd/user/argus.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

and here is the gist of the script

def main():
    args=cli(argv) #parse args

        rtc_time = Hextapus.Get_string_utc_time_pcf(0)
        logger.warning("Issuing Shutdown command at RTC Time: {}".format(rtc_time))    #Indicate os shutdown during hard shutdown and RTC time stamp      
        os.system('sudo shutdown now')    
        return 0
    except KeyboardInterrupt:
        #This is so when debugging the loops are killed quickly
        logger.warning("Keyboard ESCAPE detected. Shutting Down")

if __name__ == '__main__':

Because the service issues a shutdown on the pi when I run systemctl --user start argus I see the following in journalctl

Dec 03 20:35:39 raspberrypi python3[27653]: 2020-12-03 20:35:39,502 - WARNING - Issuing Shutdown command at RTC Time: 20201203203543
Dec 03 20:35:43 raspberrypi systemd[385]: Stopping RAL Argus Service...
Dec 03 20:35:43 raspberrypi systemd[385]: argus.service: Main process exited, code=killed, status=15/TERM
Dec 03 20:35:43 raspberrypi systemd[385]: argus.service: Succeeded.
Dec 03 20:35:43 raspberrypi systemd[385]: Stopped RAL Argus Service.

There is no further info in journalctl on the subsequent boot to say the service is running or couldn't start. I'm not sure if the fact that the script issues a shutdown is the cause of my problem.


2 Answers 2


If you try to run the service under an user instance of systemd you should be using default.target not multi-user.target. multi-user.target is not used by the user instance of systemd.

See https://www.freedesktop.org/software/systemd/man/systemd.special.html#default.target1


Your service is not starting because pi's --user bus does not start until pi logs in. While Michal's answer was partially right (you should use default.target instead of multi-user.target in --user mode), the best answer is to put your service on the system bus.

If you want to run this service even without pi logging in, then put it on the system bus. This involves:

  • mv ~/.config/systemd/user/argus.service /etc/systemd/system/
  • Add User=pi to the [Service] section of argus.service.

Now your script has all of the same permissions as if it were run by pi on the user bus, except it runs independently of the user-login status. The only disadvantage is you need to run sudo when handling this unit with systemctl or journalctl.

The main advantage of the --user bus is to allow the user to use systemctl or journalctl without sudo to manage specific services. It also allows starting and stopping of services based on the login or logout of the user. Since your service needs to start without the user input, and without a user login trigger, the system bus is the best place to be.

  • "user bus does not start until pi logs in", unless freedesktop.org/software/systemd/man/… Dec 4, 2020 at 14:41
  • True, but then you need to add loginctl to a startup script somewhere. That's really working around the intent of the command.
    – Stewart
    Dec 4, 2020 at 16:17
  • Unless loginctl enable-linger is persistent. There is no option for enable-linger in /etc/systemd/logind.conf, and I can't really find anything to suggest it is persistent other than "a user manager is spawned for the user at boot "
    – Stewart
    Dec 4, 2020 at 16:38
  • 1
    Yes it is, precisely because of what you say. But the documentation could be clearer. It seems to work like this: serverfault.com/a/849280 Dec 4, 2020 at 16:46
  • Thanks. I learned something today!
    – Stewart
    Dec 4, 2020 at 16:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .