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)
– ButtinkAug 4 '10 at 20:20

1

This entire answer thread is a mess. The Stack Exchange format doesn't seem to be best suited for this question
– Gabriel FairFeb 25 '18 at 19:09

It's actually quite entertaining. How many different ways could there be?
– devios1May 15 '18 at 22:12

9 Answers
9

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

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 ChoudhuryFeb 4 '13 at 4:03

2

What if i need to run the command as root?
– dopatramanJul 15 '15 at 1:58

1

@dopatraman The answer states that all processes with this are run as root.
– AStopherOct 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+).
– user364819Jan 9 '16 at 18:52

3

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?
– BlauhirnAug 7 '16 at 17:49

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 TOct 10 '13 at 7:17

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.

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

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 Brazilian GuyJan 23 '13 at 16:13

1

@ruda.almeida Thanks for pointing that out. The answer was written in the pre-Unity days.
– Riccardo MurriJan 23 '13 at 16:48

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

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

is it possible to set a priority on the job? or specify that it depends on another service to be started first?
– r3wtApr 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
– muruJan 3 '18 at 6:07

@PerlDuck not the only thing it was lacking. Thanks!
– muruMar 5 '18 at 13:53

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 have RemainAfterExit=no.
– PerlDuckMar 5 '18 at 14:19

@PerlDuck There's nothing inherent in df that needs RemainAfterExit=no. Unless you want to repeatedly execute the command each time you run systemctl start foo.
– muruMar 5 '18 at 14:32

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

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:

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.
– WinEunuuchs2UnixJan 3 '18 at 5:58

2

Oh, please. You and I both know that the editor can be changed.
– muruJan 3 '18 at 5:59

@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.
– WinEunuuchs2UnixJan 3 '18 at 6:09

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