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. 
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 
Ah, forgot:
sudo systemctl enable serviceName.
To get the service enabled to start at boot.
systemd is essentially malware. I wonder how they force all those distributors to adopt it 
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
you can look at takeoff app i guess, that starts apps at start, so …
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.
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.
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.
Works nicely. Thanks!
Would you anyone know, which of these targets should I use when I want to execute my script after the SD card was mounted?
(I want to automate what I currently do manually: bind mount a directory from SD card into the android_storage. I couldn’t manage to give Android app F-Stop write permissions on the SD card…)
# systemctl list-units --type target
UNIT LOAD ACTIVE SUB DESCRIPTION
basic.target loaded active active Basic System
bluetooth.target loaded active active Bluetooth
cryptsetup.target loaded active active Local Encrypted Volumes
getty.target loaded active active Login Prompts
graphical.target loaded active active Graphical Interface
local-fs-pre.target loaded active active Local File Systems (Pre)
local-fs.target loaded active active Local File Systems
multi-user.target loaded active active Multi-User System
network-online.target loaded active active Network is Online
network.target loaded active active Network
paths.target loaded active active Paths
remote-cryptsetup.target loaded active active Remote Encrypted Volumes
slices.target loaded active active Slices
sockets.target loaded active active Sockets
sound.target loaded active active Sound Card
swap.target loaded active active Swap
sysinit.target loaded active active System Initialization
timers.target loaded active active Timers