How can I run scripts automatically when Ubuntu starts up so I don't have to run them manually after startup?
-
7If someone could also show both WHEN and WHERE that would be awesome. I say this because I know there are at least 2 ways to start a script that will fire before other applications have been started (like X11)– David StockingAug 4, 2010 at 20:20
-
4This entire answer thread is a mess. The Stack Exchange format doesn't seem to be best suited for this question– Gabriel FairFeb 25, 2018 at 19:09
-
4+1 to @GabrielFair. A LARGE part of the problem is that the original question and answer are TEN YEARS OLD. I'd also add that there are too many ways to solve this problem. What happened to the simplicity of the Unix philosophy?! Request someone knowledgeable and with sufficient points rewrite this post, or add a new, up-to-date, definitive answer for modern os versions.– Malik A. RumiJun 14, 2020 at 9:17
10 Answers
One approach is to add an @reboot cron task:
- Running
crontab -e
will allow you to edit your cron. Adding a line like this to it:
@reboot /path/to/script
will execute that script once your computer boots up.
-
114
-
28
-
6So... this wouldn't run if I lost power and the PC turned again when power is restored? Jun 21, 2012 at 19:27
-
32@siamii:
man 5 crontab
says that@reboot
is executed on startup (when cron daemon is started).– jfsMar 29, 2013 at 16:04 -
10This is awesome. So far this seems better than
rc.local
since the system seems more setup by this point (PATH, etc). It is odd that it is so hard to call something after system startup.. Oct 10, 2013 at 7:17
Depending on what sort of scripts you need to run.. For services and the like you should use upstart. But for a user script these should be launched as session scripts by gnome! Have a look under System > Preferences > Startup Applications.
On a side note if you need some scripts to be run on terminal login you can add them to the .bash_login file in your home directory.
For 14.04 and older
A simple command (one which doesn't need to remain running) could use an Upstart job like:
start on startup
task
exec /path/to/command
Save this in a .conf
file in /etc/init
(if you need it to run as root when the system boots up), or in ~/.config/upstart
(if you need it
to run as your user when you log in).
-
63Considering how SO and StackExchange runs, could you give an example of an upstart script and where it would be placed? That would make this a much better answer. Your link says it's not being maintained and to look at the upstart cookbook, which is huuuge. I don't have too much of an idea where to start. Feb 4, 2013 at 4:03
-
5
-
5Please update this answer to explain what to do on systems running systemd rather than upstart (Ubuntu 15.04+).– user364819Jan 9, 2016 at 18:52
-
4This answer does not make sense to me. The applications listed in
system->pref->startup applications
can neither be found in/etc/init/
nor in~/.config/upstart
. So where are startup applications defined?– phil294Aug 7, 2016 at 17:49 -
5
You can add commands to /etc/rc.local
:
sudo nano /etc/rc.local
This executes the commands as root.
To execute commands as a specific user, use sudo -i -u
(-i
to also run the login shell). For example, to establish a persistent SSH tunnel, where myhost
is definde in johndoe
s ~/.ssh/config
file:
sudo -i -u johndoe autossh -nNT -L 1234:localhost:1234 myhost
Note that if /etc/rc.local
did not exist (as is the case on Ubuntu since 16.04), you need to add a shebang line at the top (e.g. #!/bin/bash
), and ensure the file is executable:
sudo chmod a+x /etc/rc.local
-
27This most directly answers the question: how to simply execute some scripts when your system boots. upstart does a more complex task: starts daemon processes. Aug 7, 2013 at 19:01
-
1So upstart starts daemon processes while /etc/rc.local starts bash scripts?– DonatoMay 10, 2015 at 18:51
-
7
-
7
-
6Note that if you make this file yourself (like I did), then you will have to change file to executable with
chmod 755 rc.local
, and add#!/bin/bash
to the first line.– psitaeAug 2, 2017 at 16:42
For 15.04 and later:
To run a (short-lived)1 command at startup using systemd
, you can use a systemd unit of type OneShot
. For example, create /etc/systemd/system/foo.service
containing:
[Unit]
Description=Job that runs your user script
[Service]
ExecStart=/some/command
Type=oneshot
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
Then run:
sudo systemctl daemon-reload
sudo systemctl enable foo.service
Essentially, this is just converting a typical Upstart job to a systemd one (see Systemd for Upstart users).
You can run multiple commands from the same service file, using multiple ExecStart
lines:
[Service]
ExecStart=/some/command
ExecStart=/another/command some args
ExecStart=-/a/third/command ignore failure
The command must always be given with the full path. If any command fails, the rest aren't run. A -
before the path tells systemd to ignore a non-zero exit status (instead of considering it a failure).
Relevant:
For user sessions, you can create the systemd unit in ~/.config/systemd/user
instead. This should work with 16.04 onwards, but not earlier releases of Ubuntu with systemd (since those still used Upstart for user sessions). User session units can be controlled with the same commands as with system services, but with the --user
option added:
systemctl --user daemon-reload
systemctl --user status foo.service
Shell syntax
Note that, unlike Upstart, systemd doesn't run the Exec*
commands through a shell. It performs some limited variable expansion and multiple command (separated by ;
) itself, but that's about it as far as shell-like syntax goes. For anything more complicated, say redirection or pipes, wrap your command in sh -c '...'
or bash -c '...'
.
1As opposed to long-lived daemons.
-
is it possible to set a priority on the job? or specify that it depends on another service to be started first?– r3wtApr 25, 2017 at 0:38
-
1@r3wt yes, there are different ways to do that. The
WantedBy
used here, for example, makes it start when themulti-user.target
is reached. You can useBefore
,After
,Requires
, etc. Seeman systemd.unit
– muruJan 3, 2018 at 6:07 -
-
You're welcome. — Btw, the
RemainAfterExit
depends on the service you start and its desired behaviour. For instance,/bin/df -h
<s>would</s> should haveRemainAfterExit=no
.– PerlDuckMar 5, 2018 at 14:19 -
1The difference comes when you issue
systemctl status foo
: with RemainAfterExit=yes it says active while with RemainAfterExit=no it doesn't. However.– PerlDuckMar 5, 2018 at 15:22
There are different ways to automatically run commands:
The upstart system will execute all scripts from which it finds a configuration in directory
/etc/init
. These scripts will run during system startup (or in response to certain events, e.g., a shutdown request) and so are the place to run commands that do not interact with the user; all servers are started using this mechanism.You can find a readable introduction to at: http://upstart.ubuntu.com/getting-started.html the man pages
man 5 init
andman 8 init
give you the full details.A shell script named
.gnomerc
in your home directory is automatically sourced each time you log in to a GNOME session. You can put arbitrary commands in there; environment variables that you set in this script will be seen by any program that you run in your session.Note that the session does not start until the
.gnomerc
script is finished; therefore, if you want to autostart some long-running program, you need to append&
to the program invocation, in order to detach it from the running shell.The menu option System -> Preferences -> Startup Applications allows you to define what applications should be started when your graphical session starts (Ubuntu predefines quite some), and add or remove them to your taste. This has almost the same purpose and scope of the
.gnomerc
script, except you don't need to knowsh
syntax (but neither can you use anysh
programming construct).
-
113) "This has almost the same purpose and scope of the .gnomerc script", except
.gnomerc
apparently runs before loading Unity, andStartup Applications
apparently runs after loading Unity. I had to run a program that sits on Unity's menu bar and it made a huge difference in this case! Jan 23, 2013 at 16:13 -
1@ruda.almeida Thanks for pointing that out. The answer was written in the pre-Unity days. Jan 23, 2013 at 16:48
-
1
sudo update-rc.d myscript.sh defaults
, where /etc/init.d/myscript.sh is your script, also runs it at startup. Aug 9, 2016 at 6:16
$HOME/.config/autostart
contains the startup application list. .desktop
files in this folder will be executed on startup. It may need executable permission (chmod +x startup.desktop
).
Sample example for .desktop
file:
[Desktop Entry]
Type=Application
Exec="</path/to/script>"
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=Startup Script
Here "</path/to/script>"
is replaced with path to your script.sh
If you place your script myscript
in /usr/local/bin
so that it can be executed directly by command, you can write myscript
instead of "</path/to/script>"
.
Sample example of myscript.sh
:
#!/bin/bash
<commands to be executed>
exit
Result:
.desktop
file will be launched from $HOME/.config/autostart
which execute script by Exec=
-
Doesn't work on Ubuntu 18.04.
$HOME/.config/autostart
contains but one file for dropbox, which BTW isn't executable.– MERoseJan 24, 2020 at 7:26 -
1Worked for me on Ubuntu 18.04.1. Btw. I added the desktop entry via Search -> Startup applications. The outcome is exactly the same though. Mar 3, 2020 at 11:10
-
-
or you can hardcode your password in your script , like below Exec=gnome-terminal -- sh -c 'echo "YOURPASSWORD" | sudo -S sh PATH_TO_YOUR_SCRIPT && sleep 1 && printf "\n"'– Bo ChenJan 8 at 0:45
-
For me the chmod was necessary on the .sh script rather than the .desktop file Feb 8 at 2:25
For simple things you can add a command in System->Preferences->Sessions pointing to the location of your script.
Alternatively you can add it to /etc/init.d/rc.local or make an upstart job if it's a more low level stuff.
Take a look at https://help.ubuntu.com/community/UbuntuBootupHowto for more info
cron
answer implemented different from top voted
This answer still uses cron
but uses a different method than the top voted answer. This works since Ubuntu 16.04 but probably supported much sooner. It's just that I started using cron
to run jobs when computer boots up since 16.04.
When does cron
run?
In comments someone asked "when do they run?". You can tell in syslog / journalctl:
$ journalctl -b | grep cron
Jan 02 16:54:40 alien cron[919]: (CRON) INFO (pidfile fd = 3)
Jan 02 16:54:40 alien cron[919]: (CRON) INFO (Running @reboot jobs)
Jan 02 16:54:40 alien systemd[1]: Started Run anacron jobs.
Jan 02 16:54:40 alien anacron[949]: Anacron 2.3 started on 2018-01-02
Jan 02 16:54:40 alien anacron[949]: Normal exit (0 jobs run)
Jan 02 16:54:40 alien CRON[952]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 02 16:54:40 alien CRON[954]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 02 16:54:40 alien CRON[951]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 02 16:54:40 alien CRON[950]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 02 16:54:40 alien CRON[985]: (root) CMD ( /usr/local/bin/cron-reboot-cycle-grub-background)
Jan 02 16:54:40 alien CRON[954]: pam_unix(cron:session): session closed for user root
Jan 02 16:54:40 alien cron[919]: sendmail: Cannot open smtp.gmail.com:587
Jan 02 16:54:40 alien CRON[952]: pam_unix(cron:session): session closed for user root
Jan 02 16:54:40 alien cron[919]: sendmail: Cannot open smtp.gmail.com:587
Jan 02 16:54:40 alien CRON[950]: pam_unix(cron:session): session closed for user root
One thing to note is cron
can email you status of jobs run and @reboot
jobs run so early network manager and email won't be running unless you put a sleep
command into your script(s).
Where to put your scripts
Put your scripts in the directory /etc/cron.d
:
$ ll /etc/cron.d
total 44
drwxr-xr-x 2 root root 4096 Nov 26 19:53 ./
drwxr-xr-x 139 root root 12288 Dec 31 13:58 ../
-rw-r--r-- 1 root root 244 Dec 28 2014 anacron
-rw-r--r-- 1 root root 148 Feb 18 2017 cycle-grub-background
-rw-r--r-- 1 root root 138 Mar 5 2017 display-auto-brightness
-rw-r--r-- 1 root root 460 Nov 26 19:53 nvidia-hdmi-sound
-rw-r--r-- 1 root root 102 Feb 9 2013 .placeholder
-rw-r--r-- 1 root root 224 Nov 19 2016 touch-vmlinuz
-rw-r--r-- 1 root root 700 Aug 5 11:15 turn-off-hyper-threading
What does a script look like?
Here are a couple of scripts I have setup to run each boot:
$ cat /etc/cron.d/cycle-grub-background
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
@reboot root /usr/local/bin/cron-reboot-cycle-grub-background
$ cat /etc/cron.d/touch-vmlinuz
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
@reboot root touch "/boot/vmlinuz-"`uname -r`
-
1There are many different ways to add cronjobs, but the core of the highly voted answer and your answer is still the
@reboot
.– muruJan 3, 2018 at 5:40 -
Alternate methods for adding crontabs should be posted to askubuntu.com/q/2368/158442, which is explicitly about adding Cron jobs.– muruJan 3, 2018 at 5:47
-
1I beg to differ. The core of the answer in question utilizes
crontab -e
which some consider one of the black arts due to a vim-like interface. On the other hand this answer might appeal to those whose brains are wired a certain way. We are not all cast from the same mold. Then again this answer already has one down vote so we'll let democracy take her course. Jan 3, 2018 at 5:58 -
3
-
1This is much clearer than the highly voted answer. Every answer has hundreds of comments saying "doesn't work", because this task is more subtle than the original post suggests.– apgMar 8, 2020 at 8:03
You should use upstart for this. Upstart is used for Ubuntu processes that are automatically started. It is an enhanced solution like the old System-V init.d scripts. It also allows you to put in prerequisites to the start of your script (i.e. do you need the network running? etc.)
-
3
-
If you want your script to run before systemd right after kernel starts, AFAIK the way is adding init=/path/to/script
to the kernel command line in /boot/grub/grub.cfg
or more future proof make your own menu entry in /etc/grub.d/40_custom
by copying a menu entry from /boot/grub/grub.cfg
and making needed changes (and running update-grub
after that for grub
to add your custom file to /boot/grub/grub.cfg
).
linux /boot/vmlinuz-5.4.0-26-generic ... ro quiet splash
change to
linux /boot/vmlinuz-5.4.0-26-generic ... ro quiet splash init=/path/to/script
Take care to properly put e.g. #!/bin/bash
on the first line and exec /sbin/init
(if /sbin/init
exists on your system - on mine it points to systemd) at the end to avoid kernel panic.
-
@FindOutIslamNow, well, I've mentioned adding custom file. Do you claim system update cancel custom files? Where such info is from? Mar 1 at 14:22