How can I run scripts automatically when Ubuntu starts up so I don't have to run them manually after startup?
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).
One approach is to add an @reboot cron task:
crontab -ewill allow you to edit your cron.
Adding a line like this to it:
will execute that script once your computer boots up.
You can add commands to
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
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
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
[Unit] Description=Job that runs your user script [Service] ExecStart=/some/command Type=oneshot RemainAfterExit=yes [Install] WantedBy=multi-user.target
sudo systemctl daemon-reload sudo systemctl enable foo.service
You can run multiple commands from the same service file, using multiple
[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).
For user sessions, you can create the systemd unit in
~/.config/systemd 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
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.
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 initand
man 8 initgive you the full details.
A shell script named
.gnomercin 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
.gnomercscript 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
.gnomercscript, except you don't need to know
shsyntax (but neither can you use any
$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 Entry] Type=Application Exec="</path/to/script>" Hidden=false NoDisplay=false X-GNOME-Autostart-enabled=true Name=Startup Script
"</path/to/script>" is replaced with path to your
If you place your script
/usr/local/bin so that it can be executed directly by command, you can write
myscript instead of
Sample example of
#!/bin/bash <commands to be executed> exit
.desktop file will be launched from
$HOME/.config/autostart which execute script by
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.
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: (CRON) INFO (pidfile fd = 3) Jan 02 16:54:40 alien cron: (CRON) INFO (Running @reboot jobs) Jan 02 16:54:40 alien systemd: Started Run anacron jobs. Jan 02 16:54:40 alien anacron: Anacron 2.3 started on 2018-01-02 Jan 02 16:54:40 alien anacron: Normal exit (0 jobs run) Jan 02 16:54:40 alien CRON: pam_unix(cron:session): session opened for user root by (uid=0) Jan 02 16:54:40 alien CRON: pam_unix(cron:session): session opened for user root by (uid=0) Jan 02 16:54:40 alien CRON: pam_unix(cron:session): session opened for user root by (uid=0) Jan 02 16:54:40 alien CRON: pam_unix(cron:session): session opened for user root by (uid=0) Jan 02 16:54:40 alien CRON: (root) CMD ( /usr/local/bin/cron-reboot-cycle-grub-background) Jan 02 16:54:40 alien CRON: pam_unix(cron:session): session closed for user root Jan 02 16:54:40 alien cron: sendmail: Cannot open smtp.gmail.com:587 Jan 02 16:54:40 alien CRON: pam_unix(cron:session): session closed for user root Jan 02 16:54:40 alien cron: sendmail: Cannot open smtp.gmail.com:587 Jan 02 16:54:40 alien CRON: 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
$ 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`
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.)