Launch a Bluetooth Low Energy command after raspberry startup

Question

I wrote a command in swift that uses the internal bluetooth low energy module of my Raspberry PI 4. This command must be launched as superuser.
Everything works perfectly if I launch the executable from the terminal, but I'm struggling to make it launch automatically after the system startup.
I'm trying to use the systemd, following this guide . I've created my punch.service inside the /lib/systemd/system/ and followed the step to enable it. The software is running after startup and I can tell it because I'm also using the GPIO to command some leds, but the raspberry doesn't seems to advertise and is not available to accept connections.
If I kill the process and launch the executable again it starts to advertise too. My service file looks like this:

[Unit]
Description=Punch service
After=bluetooth.target
After=multi-user.target

[Service]
ExecStart=/home/pi/Desktop/RaspberryBLE/PunchBLE/.build/release/RaspberryBLE

[Install]
WantedBy=bluetooth.target
WantedBy=multi-user.target

I suppose that this will tell the system to launch the executable after bluetooth service are up and running, but it doesn't seems so.
Doesn't matter if startup the raspberry on desktop or CLI with autologin. Am I missing something? Is there a way to make it sure that my service is launched as last?

Answer 1

systemd will give you some flexibility, but if you want to get something running right away - while you fiddle with systemd - you might consider a cron job. Here's a simple approoach:

1. As user pi (or any user with sudo privileges, edit the root crontab as follows:

$ sudo crontab -e

2. Once the root crontab is open in your editor, add a line similar to this:

@reboot sleep 30; /path/to/your/executable >> /home/pi/mybtcronlog.txt 2>&1

3. Reboot to test

How it works:

1. Any job started in the root crontab will run as the superuser (root) - (Hint: Don't ever use sudo in a cron job.)

2. The crontab is simply the schedule table used by cron to start jobs. See man crontab for syntax & crontab guru if you need help with the schedule expression. @reboot is a special schedule, so you won't likely need any help with that.

The crontab entry shown above tells cron to run two commands sequentially:

• sleep for 30 seconds, and then
• run your executable bluetooth app. - give it the full path to the exe

Unlike systemd, cron has no knowledge of the status of system services^NOTE required in your program. We compensate for that by sleeping for 30 seconds to give the system time to get BT started. Nothing magic about 30 secs - it may take 5 seconds, or it may take 2 minutes - depending on your system.

• >> is a redirect meaning that any text output will go to the designated file: /home/pi/mybtcronlog.txt
• 2>&1 redirects stderr to stdout - both streams will now appear in your log file, giving you some feedback in the event something goes wrong.

3. Run sudo reboot to restart your system & test your cron job.

---

NOTE: In the paradox that is systemd design logic, the cron daemon is actually started/controlled by a systemd unit. It therefore seems odd that the systemd designers did not provide a method to allow cron users to communicate their job's service dependencies. systemd is useful in many respects, but it can become rather complex for what would seem to be simple tasks; e.g. why can't systemd start cron as the last service during startup?

Answer 2

Can't promise this will solve your problem, but...

I suppose that this will tell the system to launch the executable after bluetooth service are up and running, but it doesn't seems so

Something to keep in mind with system services is that it is very easy for the system to determine and depend upon when a service starts, but that is very narrowly defined in the sense that it will often be distinct from the not as simple and objectively definable "up and running" -- which may be easy to define in words for a specific service, but there are no checkpoints of that sort in general (there are some good reasons for this but I'll refrain from the tangent).

The take-away is that, in general, all the various depends/wants etc. are based on when processes start. With the systemd "targets", which group services, the relationship between core services in a target does provide a bit of checkpoint-esque ordering refinement, but even without the added complication of stage 1, 2, 3 etc for every process this can be a bit delicate.

So, this seems to me wrong-headed:

After=bluetooth.target
After=multi-user.target
[...]
WantedBy=bluetooth.target
WantedBy=multi-user.target

As per man systemd.unit:

It is a common pattern to include a unit name in both the After= and Wants= options, in which case the unit listed will be started before the unit that is configured with these options.

But, as per the Forward and reverse unit properties table in that man page, Wants is the reverse of WantedBy. So you are sort of saying that this service should start after bluetooth.target (and multi-user.target), but that this service should start when those targets start. It creates a sort of circular or non-sensical dependency.

WRT WantedBy, this is just what indicates where and if the service should be included when you enable it. The simplest and most straight-forward way to use it is to just use default.target. This means it will be included in the list of thing to start without nailing it down too specifically -- that can be fine tuned with dependencies on more specialized units/targets.

Obviously you need bluetooth working, and if you read through the bit on Wants=, Requires=, and After, something more appropriate might be:

[Unit]
Description=Punch service
Requires=bluetooth.service
After=bluetooth.service

[Service]
ExecStart=/home/pi/Desktop/RaspberryBLE/PunchBLE/.build/release/RaspberryBLE

[Install]
WantedBy=default.target

Notice I've used bluetooth.service there, not bluetooth.target. This is because if you look, by default the bluetooth.target only includes one service, bluetooth.service, and since that is an actual service that starts a real executable, it is likely to be a more specific relation.