Creating a systemd user service on your Raspberry Pi

Flushed with success from yesterday’s post where I made my first systemd service, I got carried away and wanted to show you how to create a service that runs as a regular user.

A fairly common question on the Raspberry Pi Forums is “How do I run a script every time I reboot?”. The traditional answer (and one I’ve given more than once) is to add a @reboot clause to your crontab. This will indeed run a command when the computer reboots, but it will run pretty early on in the boot sequence when there’s no guarantee of network or time services. So the usual remedy is a bit of a kludge:

@reboot sleep 60 && 

This waits a full minute after rebooting, then executes the command. Network and time services are really likely to be available, but it’s not very elegant. Cron also has some weird gotchas with PATH settings, so while it’s ubiquitous and has worked for decades, it’s not easy to get working. Systemd, however, has a much better way of doing it, and better yet, you can do it all without ever hitting sudo.

I’ll take as a basis for this post the forum query “python and crontab”. The asker wanted to log the time when their Raspberry Pi had rebooted, but they’ve hit the usual problem that the clock didn’t have the right time when their script was triggered, so the log was useless.

(I’m not going to do exactly what the forum poster did, but this is more a demo of a systemd user service than recreating their results.)

First off, here’s the script to log the time to a file (saved as ~/bin/

from time import strftime
with open("/home/pi/logs/boot_time.txt", "a") as log:

I’d have done this as a shell script, but the OP used Python, so why fight it?

FUN FACT: Under most Linux flavours, if you create a bin folder in your home directory, it’s automatically added to your path. So I could just type and the shell would find it.
(You might have to log out and log back in again for the shell to review your path.)

In order to get that to run, I need to do a little housekeeping: make the script executable, and make sure the logs folder exits:

chmod +x ~/bin/
mkdir -p ~/logs

Now we need to do the bits that pertain to systemd. First off, you must make a folder for user services:

mkdir -p ~/.config/systemd/user

NOTE: mkdir -p … is useful here as it makes the directory and any parent directories that don’t exist. It also doesn’t complain if any of them already exist. It’s kind of a “make sure this directory exists” command. Make friends with it.

And here’s the service file, which I saved as ~/.config/systemd/user/boot_time_log.service:

Description=boot time log



The service file does the following (even if I’m slightly mystified by some of the headings …):

  • Unit
    • Description — a plain text name for the service. This appears in logs when it starts, stops or fails.
    • DefaultDependencies — as this service runs once at boot-up, it doesn’t need the normal systemd functions of restarting and shutting down on reboot. Most service files omit this line.
    • After — here we tell systemd what service targets must be running before this service is started. As we need to write to a file and have the right time, the and seem sensible.
  • Service
    • Type — this is run once, so it’s a oneshot rather than the usual simple service.
    • ExecStart — this is the command to run when the service is required.
  • Install
    • WantedBy — tbh no idea what this does, but if you omit it the service won’t install. Found the answer in this SE, and it works. So I guess what it does is make the service not fail

Finally, you enable the service with:

systemctl --user enable boot_time_log.service

Next time you reboot, the time will be appended to the log file ~/logs/boot_time.txt.

Unlike most (that is, Type=simple) services, it’s perfectly fine if this one spends most of its time inactive:

$ systemctl status --user boot_time_log.service
● boot_time_log.service - boot time log
 Loaded: loaded (/home/pi/.config/systemd/user/boot_time_log.service; enabled;
 Active: inactive (dead) since Sun 2017-10-22 22:17:56 EDT; 1h 5min ago
 Process: 722 ExecStart=/home/pi/bin/ (code=exited, status=0/SUCCES
 Main PID: 722 (code=exited, status=0/SUCCESS)

It has executed successfully, so the process doesn’t have to stick around.

Combined Restart / Shutdown Button for Raspberry Pi

A very simple systemd service for Raspberry Pi that provides a software-controlled restart / shutdown button. Code: scruss/shutdown_button


Default behaviour is:

  • your Raspberry Pi will reset if the button is held for more than two seconds but fewer than five seconds;
  • your Raspberry Pi will shut down if the button is held for more than five seconds.

By default, the software assumes the switch is connected to pin BCM 27. Both the pin and the timing can be changed in the Python source file.



  • A Raspberry Pi (tested on a model 2B, 3B and Zero)
  • A normally open, momentary contact button. I use surplus ATX power buttons (as used on desktop PCs), as they’re cheap and come with a handy set of wires and header connectors. Virtually any button will do the job, though. Just make sure it’s normally open (push to close).


  • A Debian-based operating system that uses systemd (tested on Wheezy [RetroPie] and Stretch)
  • the python3-gpiozero package to provide GPIO Zero (tested on version 1.4.0)



Connect the button between GPIO 27 and GND. If you use an ATX power button and a Raspberry Pi with a 40-pin GPIO header, connect it across the seventh column from the left:

· · · · · ·|·|· · · · · · · · · · · · · 
· · · · · ·|·|· · · · · · · · · · · · · 

This shorts GPIO 27 (physical pin 13) to ground (physical pin 14) when the button is pressed.


The software is installed with the following commands:

sudo apt-install python3-gpiozero
sudo mkdir -p /usr/local/bin
chmod +x
sudo cp /usr/local/bin
sudo cp shutdown_button.service /etc/systemd/system
sudo systemctl enable shutdown_button.service
sudo systemctl start shutdown_button.service


Enabling the service should produce output very similar to:

Created symlink /etc/systemd/system/ → /etc/systemd/system/shutdown_button.service.

You can check the status of the program at any time with the command:

systemctl status shutdown_button.service

This should produce output similar to:

● shutdown_button.service - GPIO shutdown button
   Loaded: loaded (/etc/systemd/system/shutdown_button.service; enabled; vendor 
   Active: active (running) since Sat 2017-10-21 11:20:56 EDT; 27s ago
 Main PID: 3157 (python3)
   CGroup: /system.slice/shutdown_button.service
           └─3157 /usr/bin/python3 /usr/local/bin/

Oct 21 11:20:56 naan systemd[1]: Started GPIO shutdown button.

If you’re seeing anything other than Active: active (running), it’s not working. Does the Python script have the right permissions? Is it in the right place? If you modified the script, did you check it for syntax errors?

The output from dmesg will show you any error messages generated by the service.


If you use a HAT/pHAT/Bonnet/etc. with your Raspberry Pi, check to see if it uses BCM 27. If you do need to change the pin, best to pick one that doesn’t have a useful system service like serial I/O or SPI. If you’re using an ATX button with a two pin connector, make sure you choose a pin physically adjacent to a ground pin.

If you modify the timing, please ensure that you keep the shutdown button press duration longer than the reboot one. Otherwise you’ll only be able to shut down.


You should not need to reboot to enable the service. One machine of mine — a Raspberry Pi Zero running Raspbian Stretch — did need a reboot before the button worked.

The reboot code is based on the Shutdown button example from the GPIO Zero documentation.

This is not the only combined shutdown/reset button project to use GPIO Zero. gilyes/pi-shutdown also does so, but pre-dates the implementation of the various hold time functions in GPIO Zero.

GPIO 27 was used, as it’s broken out onto a physical button on the Adafruit PiTFT+ display I own.

This is my first systemd service, and I’m still at the “amazed it works at all” stage. The service file may not contain the ideal configuration.

Raspberry Pi combined reboot/shutdown button demo

NB: this version doesn’t actually do the rebooting or shutting down: it’s a demo. This one does, though …

Here’s how you might have just one button being a reset button (hold down for two seconds) or a shutdown button (hold down for five):

taking the whole proto-plate thing a bit far …

Yes, it’s a very tiny microcontroller board and breadboard doohickey. The board’s a Trinket M0 running CircuitPython 2.0. The base is laser-cut birch ply. Definitely #smol  at less than 75 × 55 mm …

Here’s the SVG for laser cutting:
To build it, you’ll need:

  • 3 mm birch ply (at least 75 mm × 55 mm)
  • Adafruit Trinket M0
  • Tiny breadboard: either a tiny or a Mini one. The board markings match either.
  • M2.5 screws and standoffs
  • 4× stick-on feet
  • 2× 1×5 female header — I cut down a 1×12 female header.

If I were to redesign this, I’d:

  1. make the breadboard outline a score line rather than an etched area. Scoring is much quicker than etching.
  2. Mark pin definitions on the plate. They’re a bit hard to read on the Trinket M0.

Obligatory blinky code for running a 16 LED NeoPixel Ring and the LED in the middle of the Trinket:

*ALL* of the memory …

World domination soonish!

I’ve got a whole bunch of bytes free now I’ve upgraded my 6502 40th Anniversary Computer Badge to 32KB of RAM! I suspect I’ll end up as I usually do, Corvax-style …

Important research: was the Eudora “New Mail” chime from Ren & Stimpy’s “LOG”?

Inspired (obliquely) by this Metafilter post, I set out to answer a burning question.

LOG chime

This occurs from second 36 to second 38 of this video:

The chime when extracted without further processing, sounds like this:

(direct link: Original-Log-Commercial_The-Ren-and-Stimpy-Show.wav)

Eudora chime

I found a copy of Eudora Mail 1.44 for Windows (bundled up in an archive quaintly called “”) here. The EUDOR144.EXE file is itself a Zip archive, and contains several files. The important one is WEUDORA.EXE (722,944 bytes; SHA256 checksum a35f2ef1e95242228381d9340fff0995f4935223f88a38b9200717107252dfb9).

This is a Windows 16 “New Executable” (NE) file, and I used panzi/mediaextract to scan and extract the RIFF/WAV data:

(direct link: WEUDORA.EXE_000a8200.wav)

They sure sound similar. But are they … the same?


I made sure that both samples were set to the same rate, and I applied simple amplification in Audacity so that they both had a peak volume of -3 dB. Aligning the tracks as best I could, I got this:

Log audio on top, Eudora chime underneath

The Eudora sample is very slightly slower than the Log one. It might have been that the Eudora authors sampled the chimes from an analogue video tape. The match is remarkable, however, as they play together with only very slight phasing effects:

(direct link: Log_vs_Eudora-log_left-Eudora_right.wav)


Yes, the Eudora Mail “New Mail” chime did come from Ren & Stimpy after all.

MS Word will break your links!

I was pleased to see that my nerrrdy Bourgoin mini-zine got cited in an art workbook for schools: Islamic mosaics activity (Patterning) from MathWeave. Yay!

But the link in the workbook doesn’t work! I mean, it looks right:

While the real link is:

Only when you copy the bad URL do you see the problem:

Word has changed the pasted ‘-’s to ‘‐’s: that’s from U+002D HYPHEN-MINUS to U+2010 HYPHEN. You’d have thought that software that was smart enough to recognize an URL would also be smart enough not to do any messing with the characters in it …

Most of the Logic Apple II Library now on

Well, that’s all the disks I can find easily up on There are some Apple IIgs disks still to do, and there might be some random disks lurking in another box, but that’s more than 485 disk images uploaded.

You can find them by going to Internet Archive Search: creator:”LOGIC (“Loyal Ontario Group Interested In Computers”)”.