up vote 398 down vote favorite
188

How can I run scripts automatically when Ubuntu starts up so I don't have to run them manually after startup?

share|improve this question

This question has an open bounty worth +50 reputation from Fabby ending in 5 days.

One or more of the answers is exemplary and worthy of an additional bounty.

Muru's answer needs a bit of help to climb up the ranks because the other existing answers are outdated. :-)
2  
If 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) – Buttink Aug 4 '10 at 20:20
up vote 169 down vote accepted

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).

share|improve this answer
50  
Considering 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. – Ehtesh Choudhury Feb 4 '13 at 4:03
1  
What if i need to run the command as root? – dopatraman Jul 15 '15 at 1:58
1  
@dopatraman The answer states that all processes with this are run as root. – cybermonkey Oct 24 '15 at 11:43
4  
Please update this answer to explain what to do on systems running systemd rather than upstart (Ubuntu 15.04+). – Paranoid Panda Jan 9 '16 at 18:52
2  
This 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? – Blauhirn Aug 7 '16 at 17:49
up vote 406 down vote

One approach is to add an @reboot cron task:

  1. Running crontab -e will allow you to edit your cron.

  2. Adding a line like this to it:

    @reboot /path/to/script

    will execute that script once your computer boots up.

share|improve this answer
67  
The @reboot keyword is a nice tip because it is not widely known. – jathanism Aug 11 '10 at 13:39
9  
Nice. Any idea exactly when this triggers? – Oli♦ Feb 2 '11 at 13:54
2  
So... this wouldn't run if I lost power and the PC turned again when power is restored? – Mike Wills Jun 21 '12 at 19:27
16  
@siamii: man 5 crontab says that @reboot is executed on startup (when cron daemon is started). – jfs Mar 29 '13 at 16:04
6  
This 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.. – Karthik T Oct 10 '13 at 7:17
up vote 111 down vote

How about adding the command to /etc/rc.local? you'll have to use sudo access though to edit this file.

sudo nano /etc/rc.local
share|improve this answer
10  
This most directly answers the question: how to simply execute some scripts when your system boots. upstart does a more complex task: starts daemon processes. – Dogweather Aug 7 '13 at 19:01
1  
So upstart starts daemon processes while /etc/rc.local starts bash scripts? – Donato May 10 '15 at 18:51
4  
This should be the accepted answer... – Android Dev Nov 23 '16 at 19:23
1  
Should it? This no longer works these days, right? – DaVince Apr 28 '17 at 8:29
1  
Note 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. – psitae Aug 2 '17 at 16:42
up vote 65 down vote

There are different ways to automatically run commands:

  1. 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 and man 8 init give you the full details.

  2. 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.

  3. 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 know sh syntax (but neither can you use any sh programming construct).

share|improve this answer
8  
3) "This has almost the same purpose and scope of the .gnomerc script", except .gnomerc apparently runs before loading Unity, and Startup 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! – That REDACTED Guy Jan 23 '13 at 16:13
1  
@ruda.almeida Thanks for pointing that out. The answer was written in the pre-Unity days. – Riccardo Murri Jan 23 '13 at 16:48
    
sudo update-rc.d myscript.sh defaults, where /etc/init.d/myscript.sh is your script, also runs it at startup. – Dan Dascalescu Aug 9 '16 at 6:16
up vote 28 down vote

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

[Install]
WantedBy=multi-user.target

[Service]
Exec=/some/command
Type=oneshot
RemainAfterExit=yes

Then run:

sudo systemctl daemon-reload

This is not necessary, since systemd will pick up the new unit on restart. You need to do daemon-reload if you plan to use systemctl on the new unit before restarting.

Essentially, this is just converting a typical Upstart job to a systemd one (see Systemd for Upstart users).

Relevant:

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

1As opposed to long-lived daemons.

share|improve this answer
    
is it possible to set a priority on the job? or specify that it depends on another service to be started first? – r3wt Apr 25 '17 at 0:38
1  
@r3wt yes, there are different ways to do that. The WantedBy used here, for example, makes it start when the multi-user.target is reached. You can use Before, After, Requires, etc. See man systemd.unit – muru yesterday
up vote 16 down vote 
$HOME/.config/autostart
  • This location contains startup application list.
  • .desktop file can be put here which will be executed on startup.

Sample example for .desktop file:

Putting following .desktop file in $HOME/.config/autostart and given chmod +x:

[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
(usually recommended to /usr/local/bin so-that can be executed by directly command say myscript replaced with "</path/to/script>").

Sample example of script.sh:

#!/bin/bash
<commands to be executed>
exit

Result: .desktop file will be launched from $HOME/.config/autostart which execute script by Exec=

Hence, You can run your desired shell script at startup!

share|improve this answer
up vote 15 down vote

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

share|improve this answer
up vote 2 down vote

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.)

share|improve this answer
up vote -2 down vote

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`
share|improve this answer
    
There are many different ways to add cronjobs, but the core of the highly voted answer and your answer is still the @reboot. – muru yesterday
    
Alternate methods for adding crontabs should be posted to askubuntu.com/q/2368/158442, which is explicitly about adding Cron jobs. – muru yesterday
    
I 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. – WinEunuuchs2Unix yesterday
    
Oh, please. You and I both know that the editor can be changed. – muru yesterday
    
@muru Yes probably because you taught me and I learned to change editor to something like nano or a couple of other CLI's. But I'm in the gedit camp. Besides crontab -e brings up memories of asterisks ("*") for minutes, hours, etc. that I've always found I need to google instructions for. I still find using /etc/cron.d and /etc/cron.daily my go to choice. Especially since it mirrors /etc/udev/rules.d and /etc/systemd/system-sleep methods. It just seems like a nice fit. – WinEunuuchs2Unix yesterday

protected by Community♦ Jan 14 '15 at 19:17

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.