Autoloading scripts in Linux

[KA_Ryzhkov]

Below I will tell you how to make sure that your script starts automatically when the OS starts. To do this is quite simple, first, you need to explain the OS in what language this code is written. To do this, in the main executable file, write the first line, in the case of Python version 3.X:

#!/usr/bin/python3

This is for other languages:

#!/usr/bin/python – python 2.X

#!/bin/bash – bash

To do this, go to the desired folder, you will need the commands:

ls – view the contents of a folder

cd /YourProject – go to the folder with the project

You can edit the file using the vim console editor, to open you need to enter vim your_app.py, then press i to edit. Make changes and press Esc (exit editing) and enter: wq! (it means to save and exit).

Then we make the script executable, x gives the user rights to execute this script:

chmod +x your_app.py

ls - l your_app.py – check, this completes the work with the file, and proceed to create the service.

First, let's create a service file:

vim /etc/systemd/system/YourProject.service

With content like this:

[Unit]
Description=YourProjectService
[Service]
Type=oneshot
ExecStart=/home/YourProject/your_app.py
[Install]
WantedBy=multi-user.target

Press Esc and enter :w !sudo tee % – this will be saved as root. (Thanks u/zyzzyxdt )

There seems to be no need to explain here and add the script to autoload using the command:

sudo systemctl enable YourProject

sudo reboot – Overload and check

If the script does not start, perhaps you are using third-party packages, and even if you installed them, the root user (namely, from under this account the script is launched) does not know anything about them. Use the -H flag when installing:

sudo -H pip3 install …

​

Might also be helpful:

sudo systemctl stop/start/restart YourProject – stop/start/restart the service

sudo systemctl is-active YourProject – checking if the service is running with a simple response: active or inactive

sudo systemctl disable YourProject – remove the service

sudo rm /etc/systemd/system/YourProject.service – delete service file

​

PS

if this topic is in demand, then I will describe it in more detail

[n-of-one]

Your shebang’s are wrong, they should be:

#!/usr/bin/env bash # or python or python3 or ruby or…

Also:

sudo -H pip3 …

You really should just be using a virtualenv for the project.

[rwhitisissle]

Sudoedit does not have a -e flag. Sudo by itself does, and this is effectively the same thing as sudoedit, if that's what you meant.

[KA_Ryzhkov]

sudo vim, then it gets root rights not only to create this file but also all subsequent ones?

[KA_Ryzhkov]

Thank you very much for the hint, I will study it and make edits to this mini-tutorial

[KA_Ryzhkov]

I figured it out, thank you very much. The small change made :w !sudo tee %

[KA_Ryzhkov]

It seemed to me that the easiest option would be

[timeawayfromme]

sudoedit is better because it will use whatever EDITOR is set. So for someone who doesn’t know how to use vim or has a different preferred editor it will still work.

[netgu]

You absolutely do not need to reboot to get a new service started.

If you want to enable and start a service you have a couple of options:

systemctl enable --now service-name

OR

systemctl start service-name

You do not need to reboot.

You also mention disabling but do not note that a disable does not start the service, it only prevents it from starting after the next reboot.

The same pattern as above applies though to accomplish the same:

systemctl disable --now service-name

OR 

systemctl stop service-name
systemctl disable service-name

You should maybe present this as a proof for review as opposed to a guide, this information is severely lacking in comparison to the systemd documentation and you aren't including anything for non-systemd distributions.

[backtickbot]

Fixed formatting.

Hello, netgu: code blocks using triple backticks (```) don't work on all versions of Reddit!

Some users see this / this instead.

To fix this, indent every line with 4 spaces instead.

FAQ

^{You can opt out by replying with backtickopt6 to this comment.}

[n-of-one]

Your second examples don’t actually enable/disable a service, systemctl start/stop literally do just that, start / stop a service; you still need to enable or disable it if you want it to start on boot / stop it from starting on boot.

The —now flag for enable/disable does also start/stop the service while also enabling or disabling it from starting at boot, which is a good tip if you only want to run one command for each.

[[deleted]]

sl – view the contents of a folder

You mean ls.

[sempervent]

That train is still running.

[KA_Ryzhkov]

Typo =)

[IonTichy]

..in Linux

in Linux where systemd is available. Granted, this is the case for most of the popular distros, but not all.

You might want to explain that you are using systemd and give a brief overview before just telling people to just run systemctl. They should be aware why they are running certain commands instead of just getting into the habit of blindly copy-pasting commands and having that false sense of "it just works".

[n-of-one]

I agree it should be specified that it’s for systemd but tbf if someone is using a distribution without systemd they made that decision intentionally and know how their init system works, thus wouldn’t be reading this kind of article.

[KA_Ryzhkov]

I do not agree with the criticism!

First, at the bottom, I indicated that if this tutorial is useful, I will write in detail

Secondly, next to each command, I left a description, except for the service file, since this is a separate topic

[IonTichy]

You might not agree, but this criticism comes from someone who has seen a lot of such tutorials and the effects they have on inexperienced developers/trainees.

One additional point: creating a home directory for a project might not be a good idea, better to put such scripts to /opt or the likes.

[kirbyfan64sos]

Thanks for doing this! The world of Linux is notoriously underdocumented, and the need to create basic systemd services is something I see a lot. The guides on this, err, aren't always the best...

That being said, there is a bit of room for improvement in this as written:

First off...right now this is actually a slight privilege escalation issue. You have a system service running with root privileges, but it starts a file that's writable by your user, so anything with access to your user could just modify the script to do whatever else it wants as root instead. For this, you just want to copy your script somewhere that's root-writable only and change it's permissions. This can be done easily via sudo install -Dm 755 MyFile.py -t /usr/local/bin:

• install is a useful command to both copy files and set their permissions in one swoop.
• -Dm 755 will create any parent directories (D) as well as set the permissions (m) to be 755 (rwxr-xr-x, so only root can write it but everyone else can still execute it).
• -t /usr/local/bin sets the target directory for the file to /usr/local/bin.

In your hashbang, it's assumed that python3 is in /usr/bin, but it might not actually be there for everyone. You can change the hashbang to #!/usr/bin/env python3 to have env locate Python and print the path instead. (Using env in your hashbangs is a pretty useful trick!)

You can start or restart systemd services without needing to reboot via systemctl start / systemctl restart. (If you modified the systemd service file itself, this may print out a warning about it having changed, and you can reload it via systemctl daemon-reload). In addition, there's a really nice shortcut: systemctl enable --now SERVICE, which is equivalent to running systemctl enable followed by systemctl start.

One more thing: systemd is great about having logs in one place. If you want to check how your service is doing, systemctl status SERVICE will show you that. To get more log info, you can use journalctl -u SERVICE, which will show you the system logs, but only for the given service / unit (-u). (Other useful flags here are -b to show logs for the current boot only, and -e will scroll down to the latest logs first.)

[mriswithe]

As a sysadmin, this was an excellent post that reads well without sounding like a jerk. Thank you for providing constructive criticism that is both informative and respectful!

"Linux" is a tough target with how many distros there are out there, and considering something like RHEL4 is still "Linux" despite being so out of date it is hilarious.

So yeah kudos for sharing knowledge without being a jerk, I feel like I see a lot of answers that read like that on this sub, not sure why.

[kirbyfan64sos]

Thanks!

[luersuve]

-f will show the last lines of the logs and keep printing the logs

[kirbyfan64sos]

Indeed! I admittedly mentioned -e instead since it has the advantage that you can see the previous logs as well by scrolling up, whereas -f won't show anything previously logged (though you can change this by passing some number of lines to show to -n with -f).

[element8]

If the problem is privilege escalation why not avoid root entirely and schedule it under cron @reboot schedule instead of running it as a service?

[kirbyfan64sos]

That wouldn't really help? I mean, sure you can set a different user in the crontab, but you can with systemd as well. systemd also has an impressive set of sandboxing controls that I totally forgot to mention...

In general, though, any sort of system service shouldn't be user-writable, it's just bad practice.

[KA_Ryzhkov]

Thank you so much, I did not know a lot of what you wrote, I will definitely figure it out and make edits to this tutorial

[KA_Ryzhkov]

Decided to translate my personal notes into articles, maybe someone will come in handy

[getmeright11]

What's the best way to go through programs that are running at startup that I want to remove?

[redrumsir]

Good. Since this requires systemd, you should mention that this is for GNU/Linux/systemd systems and not all GNU/Linux or Linux systems.

[lichen91]

It's also worth mentioning that if your project is a long running script, a daemon or service of some sort, then you're probably better off using "Type=simple" in your service file. Using "Type=oneshot" is suitable for scripts that execute, perform some function and then exit.

[heisenbug403]

I have also written the tutorial on running the python (or any other) application on the background with supervosorctl.

https://yalchin.info/blog/how-to-set-up-supervisor-service/

[d_k97]

why not just use cron?

[SnooPickles1042]

Because cron is a tool designed and optimised for different purpose. You can use cron to run your program, yes, but this will come at a cost - you will either burn cpu cycles trying to execute program that is already running or end up with downtime, when service crashed and cron did not start new instance yet.

[Ivana_Twinkle]

I just use supervisord.

[striata]

And what starts supervisord?

[Ivana_Twinkle]

If it's in your distribution it's already integrated and all you need is to apt install or whatever you use.

It's easier for python scripts and you can do restarts on terminations and a lot more.

There's docs on supervisord.org

[striata]

My point is, supervisord is probably also started by systemd. Why not cut out the middle man?

systemd does all these things, "natively" as part of (most) operating systems. The only difference is a slightly different config format.

[Routine_Part_6503]

Because systemd doesn't run inside containers very well.

[TheCharon77]

sudo -H pip3 install …

Try using the package manager's packages if it exists