Selon le type de scripts à exécuter .. Pour les services, vous devez utiliser upstart . Mais pour un script utilisateur, ceux-ci doivent être lancés en tant que scripts de session par gnome! Jetez un œil sous System & gt; Préférences & gt; Applications de démarrage.

Remarque: si vous avez besoin de certains scripts pour vous connecter au terminal, vous pouvez les ajouter à la . Bash_login dans votre répertoire personnel.

Pour 14.04 et plus

Une commande simple (qui n’a pas besoin de rester en cours d’exécution) pourrait utiliser un job Upstart tel que:

start on startup
task
exec /path/to/command

Enregistrez-le dans un fichier .conf dans /etc/init (si vous en avez besoin pour s'exécuter en tant que root au démarrage du système) ou dans ~/.config/upstart (si vous en avez besoin pour fonctionner en tant qu'utilisateur lorsque vous vous connectez).

Une approche consiste à ajouter une tâche @reboot cron :

1. En exécutant crontab -e , vous pourrez modifier votre cron.

2. Ajouter une ligne comme celle-ci:

   @reboot /path/to/script
   

   exécutera ce script au démarrage de votre ordinateur.

Que diriez-vous d’ajouter la commande à /etc/rc.local ? vous devrez utiliser l'accès sudo pour modifier ce fichier.

sudo nano /etc/rc.local

Il existe différentes manières d’exécuter automatiquement les commandes:

1. Le système upstart exécute tous les scripts à partir desquels il trouve une configuration dans le répertoire /etc/init . Ces scripts s'exécuteront au démarrage du système (ou en réponse à certains événements, par exemple une demande d'arrêt) et seront donc l'endroit où exécuter des commandes qui n'interagissent pas avec l'utilisateur. tous les serveurs sont démarrés en utilisant ce mécanisme.

   Vous pouvez trouver une introduction lisible à l'adresse: lien les pages de manuel man 5 init et man 8 init donnent vous les détails complets.

2. Un script shell nommé .gnomerc dans votre répertoire personnel est automatiquement généré chaque fois que vous vous connectez à une session GNOME. Vous pouvez y placer des commandes arbitraires. Les variables d'environnement que vous définissez dans ce script seront visibles par tous les programmes que vous exécuterez dans votre session.

   Notez que la session ne démarre pas tant que le script .gnomerc n'est pas terminé. par conséquent, si vous souhaitez lancer automatiquement un programme de longue durée, vous devez ajouter & à l'appel du programme afin de le détacher du shell en cours d'exécution.

3. L'option de menu Système - & gt; Préférences - & gt; Les applications de démarrage vous permettent de définir quelles applications doivent être lancées au démarrage de votre session graphique (Ubuntu en prédéfinit certaines), et de les ajouter ou de les supprimer à votre goût. L'objectif et la portée du script .gnomerc sont presque les mêmes, sauf que vous n'avez pas besoin de connaître la syntaxe sh (mais vous ne pouvez pas non plus utiliser de construction de programmation sh ).

Pour 15.04 et plus tard:

Pour lancer une commande (éphémère) ¹ au démarrage en utilisant systemd, vous pouvez utiliser une unité systemd de type OneShot . Par exemple, créez /etc/systemd/system/foo.service contenant:

[Unit]
Description=Job that runs your user script

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

[Install]
WantedBy=multi-user.target

Puis lancez:

sudo systemctl daemon-reload
sudo systemctl enable foo.service

Essentiellement, il s’agit de convertir une tâche typique de démarrage en une tâche système (voir Systemd pour les utilisateurs novices ).

Vous pouvez exécuter plusieurs commandes à partir du même fichier de service, en utilisant plusieurs lignes ExecStart :

[Service]
ExecStart=/some/command
ExecStart=/another/command some args
ExecStart=-/a/third/command ignore failure

La commande doit toujours être donnée avec le chemin complet. Si une commande échoue, le reste n'est pas exécuté. Un - avant le chemin indique à systemd d'ignorer un statut de sortie non nul (au lieu de le considérer comme un échec).

Pertinent:

• Entrée du Wiki Arch sur systemd
• man 5 systemd.service

Pour les sessions utilisateur, vous pouvez créer l’unité systemd dans ~/.config/systemd à la place. Cela devrait fonctionner avec les versions 16.04 et supérieures, mais pas les versions précédentes d'Ubuntu avec systemd (depuis celles qui utilisaient toujours Upstart pour les sessions utilisateur). Les unités de session utilisateur peuvent être contrôlées avec les mêmes commandes qu'avec les services système, mais avec l'option --user ajoutée:

systemctl --user daemon-reload
systemctl --user status foo.service

¹ Contrairement aux démons de longue durée.

$HOME/.config/autostart

• Cet emplacement contient la liste des applications de démarrage.
• Le fichier .desktop peut être placé ici et sera exécuté au démarrage.

Exemple d’exemple pour le fichier .desktop :

Mettre le fichier .desktop suivant dans $HOME/.config/autostart et chmod +x donné:

[Desktop Entry]
Type=Application
Exec="</path/to/script>"
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=Startup Script

Ici, "</path/to/script>" est remplacé par chemin vers votre script.sh
(généralement recommandé à /usr/local/bin , ce qui peut être exécuté directement par la commande say myscript remplacé par "</path/to/script>" ).

Exemple d’exemple de script.sh :

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

Résultat: Le fichier .desktop sera lancé à partir de $HOME/.config/autostart qui exécutera le script par Exec=

Par conséquent, vous pouvez exécuter le script shell souhaité au démarrage!

Pour des choses simples, vous pouvez ajouter une commande dans System- & gt; Preferences- & gt; Sessions pointant vers l'emplacement de votre script.

Sinon, vous pouvez l’ajouter à /etc/init.d/rc.local ou créer un travail upstart s'il est plus < em> truc de bas niveau .

Consultez lien pour plus d’informations

Vous devez utiliser upstart pour cela. Upstart est utilisé pour les processus Ubuntu qui sont automatiquement démarrés. C'est une solution améliorée comme les anciens scripts init.d de System-V. Il vous permet également d’introduire des conditions préalables au début de votre script (c.-à-d. Avez-vous besoin du réseau? Etc.)

cron réponse mise en œuvre différente du top voté

Cette réponse utilise toujours cron mais utilise une méthode différente de la réponse votée par le haut. Cela fonctionne depuis Ubuntu 16.04 mais probablement supporté beaucoup plus tôt. C'est juste que j'ai commencé à utiliser cron pour exécuter des travaux lorsque l'ordinateur démarre au 16.04.

Quand cron s'exécute-t-il?

Dans les commentaires, quelqu'un a demandé "quand sont-ils exécutés?". Vous pouvez dire dans 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

Une chose à noter est que cron peut vous envoyer le statut des tâches exécutées et que les tâches @reboot sont exécutées si tôt que le gestionnaire de réseau et la messagerie ne seront pas exécutés à moins

Où placer vos scripts

Placez vos scripts dans le répertoire sleep :

$ 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

À quoi ressemble un script?

Voici quelques scripts que j'ai configurés pour exécuter chaque démarrage:

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