How to start a script at boot?

Hi,

I am looking for the way to launch a script at boot.
I knew how to do that on a linux machine (link in /etc/rc5/ etc) but I fail on finding how to do it in Salilfish. I am not very used to systemd either, I have to say.
I followed the advices in this post but I guess some things have changed since it was written.
Thanks

Previous Linux systems used init scripts from /etc/init.d for decades. Unfortunately this has been mainly replaced by systemd which collects complex syntax from complex directory structure. You may have a look at /etc/systemd/<system|user>/ for some of those scripts.

You may spot some indication of my attitude towards systemd. :laughing:

2 Likes

Maybe Sailcron | OpenRepos.net — Community Repository System
etc…?

2 Likes

There are a bunch of how-tos out there:

In short, create your script,
copy it to /usr/local/bin,
make it executable

create a service file (cribbd from How-To Geek)
/etc/systemd/system/myService.service

[Unit]
Description=Service Example
Wants=network.target
After=syslog.target network-online.target
[Service]
Type=simple
ExecStart=/usr/local/bin/myService.sh
Restart=on-failure
RestartSec=10
KillMode=process
[Install]
WantedBy=multi-user.target

Make sure the service is executable.

If it’s a one shot:

[Unit]
Description=Simple Example
ConditionFirstBoot=yes
[Service]
Type=oneshot
ExecStart=/usr/local/bin/myService.sh
[Install]
WantedBy=multi-user.target

It’s a bit more tidy than putting everything in rc.local. But I do miss rc.local :slight_smile:

2 Likes

Ah, forgot:
sudo systemctl enable serviceName.

To get the service enabled to start at boot.

1 Like

systemd is essentially malware. I wonder how they force all those distributors to adopt it :thinking:

Yeah, I generally agree. The answer to your question is probably money. Red Hat. IBM. The relative power they had as sponsors of the kernel lead…

Personally, I run a mixed bag. I also run freeBSD and netBSD machines. I’ve stopped ‘hating’ it, although it is loathsome, grasping and buggy.

I’m not surprised that notoriously evil companies run it. The distributions of medium- and small-impact sometimes have me wonder … but they’re probably happy with a comparably tiny bribe for selling out their users.

But yes, except for mobile it’s rather easy to avoid.

Thanks a lot guys!

Yes, thank you. I didn’t dare to just copy. I was not sure systemctl (that I never had patience to learn) was working like on a PC.
And SFos root structure and system in general is still a bit obscure to me…

Anyways, it is now working and this is cool. :–)

I just changed this in /etc/systemd/system/myService.service:
Instead of:

Wants=network.target
After=syslog.target network-online.target

I wrote:

Requires=lipstick.service
After=lipstick.service

1 Like

you can look at takeoff app i guess, that starts apps at start, so …

1 Like

You mean Takeoff | OpenRepos.net — Community Repository System ? That’s just for ‘apps’, isn’t it? Doesn’t cover arbitrary scripts?

yes, it s apps, i did not look into code.

Also for information, @attah mentioned systemd timers.
I find interresting not to add more applications if there is already something in the system allowing to start a script at boot.
This might be lighter but less comfortable/easy though.

One doesn’t need admin rights, if app.service is saved in ~/.config/systemd/user/.
In autostart-app.service, I have

[Service]
Type=Oneshot
ExecStart=/home/nemo/.config/systemd/scripts/autostart-apps

and autostart-apps-script runs each time I restart my phone.

And running systemctl --user enable autostart-apps doesn’t require admin rights either.

2 Likes

Do you need anything in addition to what you mention?

On XA2 this gives:

$ systemctl --user enable autostart-apps
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
   instance name specified.

Don’t you miss the system file located in

/etc/systemd/system/

or in

/home/defaultuser/.config/systemd/user/

Look in post #4, it is well explained.

Is definitely the way to go if your script doesn’t do anything that requires more rights than user. I should have mentioned that when I posted initially. I was in sysadmin needs root mode. Bad habit.

2 Likes

If you refer to my post, here’s the whole autostart-apps.service:

[Unit]
Description=Execute applications at startup
Requires=lipstick.service
After=lipstick.service

[Service]
Type=Oneshot
ExecStart=/home/nemo/.config/systemd/scripts/autostart-apps

[Install]
WantedBy=post-user-session.target

I don’t know which are required and which are used. Perhaps the links in the earlier posts would tell that.

1 Like

Works nicely. Thanks!