Comment exécuter des scripts au démarrage?

français
#1

Comment puis-je exécuter des scripts automatiquement quand Ubuntu démarre, je n'ai donc pas à les exécuter manuellement après le démarrage?

#2

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

  1. Exécuter crontab -e vous permettra d'éditer votre cron.

  2. Ajouter une ligne comme celle-ci:

    @reboot /path/to/script

    exécutera ce script une fois que votre ordinateur démarrera.

#3

En fonction du type de scripts que vous devez exécuter.. Pour les services et autres, vous devez utiliser parvenu. Mais pour un script utilisateur, ceux-ci doivent être lancés en tant que scripts de session par gnome! Jetez un œil sous Système & gt; Préférences > Applications de démarrage.

En passant, si vous avez besoin que certains scripts soient exécutés lors de la connexion au terminal, vous pouvez les ajouter au .bash_login fichier dans votre répertoire personnel.

Pour les 14,04 ans et plus

Une commande simple (qui n'a pas besoin de rester en cours d'exécution) pourrait utiliser un travail de démarrage comme:

start on startuptaskexec /path/to/command

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

#4

Vous pouvez ajouter des commandes à /etc/rc.local:

sudo nano /etc/rc.local

Ceci exécute les commandes en tant que root.

Pour exécuter des commandes en tant qu'utilisateur spécifique, utilisez sudo -i -u (-i pour exécuter également le shell de connexion). Par exemple, pour établir un tunnel SSH persistant, où myhost est défini dans johndoes ~/.ssh/config fichier:

sudo -i -u johndoe autossh -nNT -L 1234:localhost:1234 myhost

Notez que si /etc/rc.local n'existait pas (comme c'est le cas sur Ubuntu depuis la 16.04), vous devez ajouter un ligne shebang au sommet (p. ex. #!/bin/bash), et assurez-vous que le fichier est exécutable:

sudo chmod a+x /etc/rc.local
#5

Pour 15.04 et plus tard:

Pour exécuter un (de courte durée)1 commande au démarrage en utilisant systemd, vous pouvez utiliser une unité systemd de type OneShot. Par exemple, créer /etc/systemd/system/foo.service contenant:

[Unit]Description=Job that runs your user script[Service]ExecStart=/some/commandType=oneshotRemainAfterExit=yes[Install]WantedBy=multi-user.target

Puis courez:

sudo systemctl daemon-reloadsudo systemctl enable foo.service

Essentiellement, il s'agit simplement de convertir un travail typique d'arriviste vers un systemd (voir Systemd pour les utilisateurs débutants).

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

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

La commande doit toujours être donnée avec le chemin complet. Si une commande échoue, les autres ne sont pas exécutées. A - avant que le chemin indique à systemd d'ignorer un état de sortie différent de zéro (au lieu de le considérer comme un échec).

Pertinent:

Pour les sessions utilisateur, vous pouvez créer l'unité systemd dans ~/.config/systemd plutôt. Cela devrait fonctionner à partir de la version 16.04, mais pas avec les versions antérieures d'Ubuntu avec systemd (car celles-ci utilisaient encore 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 le --user option ajoutée:

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

Syntaxe du shell

Notez que, contrairement à Upstart, systemd n'exécute pas le Exec* commandes via un shell. Il effectue une expansion variable limitée et plusieurs commandes (séparées par ;) lui-même, mais c'est à peu près tout en ce qui concerne la syntaxe de type shell. Pour quelque chose de plus compliqué, disons redirection ou tuyaux, enveloppez votre commande dans sh -c '...' ou bash -c '...'.

1Par opposition aux démons à longue durée de vie.

#6

Il existe différentes manières d'exécuter automatiquement des commandes:

  1. Le parvenu le système exécutera tous les scripts à partir desquels il trouvera 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 sont donc l'endroit idéal pour exécuter des commandes qui n'interagissent pas avec l'utilisateur; tous les serveurs sont démarrés à l'aide de ce mécanisme.

    Vous pouvez trouver une introduction lisible à at: http://upstart.ubuntu.com/getting-started.html les pages de manuel man 5 init et man 8 init donnez-vous tous les détails.

  2. Un script shell nommé .gnomerc dans votre répertoire personnel est automatiquement source 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 vues par n'importe quel programme que vous exécuterez dans votre session.

    Notez que la session ne démarre pas avant le .gnomerc le script est terminé; par conséquent, si vous souhaitez démarrer automatiquement un programme de longue durée, vous devez ajouter & à l'invocation 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; Applications de démarrage vous permet de définir quelles applications doivent être démarrées au démarrage de votre session graphique (Ubuntu en prédéfinit pas mal), et de les ajouter ou de les supprimer à votre goût. Cela a presque le même objectif et la même portée que le .gnomerc script, sauf que vous n'avez pas besoin de savoir sh syntaxe (mais vous ne pouvez pas non plus en utiliser sh construction de programmation).

#7

$HOME/.config/autostart contient la liste des applications de démarrage. .desktop les fichiers de ce dossier seront exécutés au démarrage. Il peut avoir besoin d'une autorisation exécutable (chmod +x startup.desktop).

Exemple d'exemple pour .desktop fichier:

[Desktop Entry]Type=ApplicationExec="</path/to/script>"Hidden=falseNoDisplay=falseX-GNOME-Autostart-enabled=trueName=Startup Script

Ici "</path/to/script>" est remplacé par le chemin d'accès à votre script.shSi vous placez votre script myscript dans /usr/local/bin pour qu'il puisse être exécuté directement par commande, vous pouvez écrire myscript au lieu de "</path/to/script>".

Exemple d'exemple de myscript.sh:

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

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

#8

Pour des choses simples, vous pouvez ajouter une commande dans >>Système-Préférences-Sessions pointant vers l'emplacement de votre script.

Alternativement, vous pouvez l'ajouter à /etc / init.d / rc.local ou faire un parvenu job si c'est un plus niveau bas truc.

Jetez un oeil à https://help.ubuntu.com/community/UbuntuBootupHowto pour plus d'informations

#9

cron réponse: différent du top voté

Cette réponse utilise toujours cron mais utilise une méthode différente de la réponse la plus votée. Cela fonctionne depuis Ubuntu 16.04 mais probablement pris en charge beaucoup plus tôt. C'est juste que j'ai commencé à utiliser cron pour exécuter des tâches lorsque l'ordinateur démarre depuis la version 16.04.

Quand est-ce que cron courir?

Dans les commentaires, quelqu'un a demandé " quand courent-ils?". Vous pouvez le dire dans syslog / journalctl:

$ journalctl -b | grep cronJan 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-02Jan 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 rootJan 02 16:54:40 alien cron[919]: sendmail: Cannot open smtp.gmail.com:587Jan 02 16:54:40 alien CRON[952]: pam_unix(cron:session): session closed for user rootJan 02 16:54:40 alien cron[919]: sendmail: Cannot open smtp.gmail.com:587Jan 02 16:54:40 alien CRON[950]: pam_unix(cron:session): session closed for user root

Une chose à noter est cron peut vous envoyer un e-mail le statut des emplois exécutés et @reboot les tâches s'exécutent si tôt que le gestionnaire de réseau et l'e-mail ne s'exécuteront pas à moins que vous ne mettiez un sleep commande dans votre script (s).

Où placer vos scripts

Mettez vos scripts dans le répertoire /etc/cron.d:

$ ll /etc/cron.dtotal 44drwxr-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/shPATH=/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-vmlinuzSHELL=/bin/shPATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin@reboot   root    touch "/boot/vmlinuz-"`uname -r`
#10

Vous devriez utiliser parvenu pour ça. Upstart est utilisé pour les processus Ubuntu qui sont démarrés automatiquement. C'est une solution améliorée comme l'ancien System-V init.d scripts. Il vous permet également de mettre des prérequis au démarrage de votre script (c'est-à-dire avez-vous besoin que le réseau fonctionne? etc.)

#11

Si vous voulez que votre script s'exécute avant systemd juste après le démarrage du noyau, AFAIK le moyen est d'ajouter init=/path/to/script à la ligne de commande du noyau dans /boot/grub/grub.cfg ou plus à l'épreuve du futur faites votre propre entrée de menu dans /etc/grub.d/40_custom en copiant une entrée de menu à partir de /boot/grub/grub.cfg et apporter les changements nécessaires (et courir update-grub après cela pour grub pour ajouter votre fichier personnalisé à /boot/grub/grub.cfg).

linux   /boot/vmlinuz-5.4.0-26-generic ... ro  quiet splash

changer pour

linux   /boot/vmlinuz-5.4.0-26-generic ... ro  quiet splash init=/path/to/script

Prenez soin de bien mettre par ex. #!/bin/bash sur la première ligne et exec /sbin/init (si /sbin/init existe sur votre système - sur le mien, il pointe vers systemd) à la fin pour éviter la panique du noyau.

#12

Si quelqu’un pouvait aussi montrer à la fois QUAND et OÙ ce serait génial. Je dis cela parce que je sais qu’il y a au moins 2 façons de démarrer un script qui se déclenchera avant le démarrage d’autres applications (comme X11)

#13

+1 à @ GabrielFair. Une GRANDE partie du problème est que la question et la réponse originales datent de DIX ANS. J’ajouterais également qu’il y a trop de façons de résoudre ce problème. Qu’est-il arrivé à la simplicité de la philosophie Unix?! Demandez à quelqu’un de * compétent* et avec suffisamment de points de réécrire ce post, ou d’ajouter une nouvelle réponse définitive et à jour pour les versions modernes du système d’exploitation.

#14

Tout ce fil de réponse est un gâchis. Le format d’échange de pile ne semble pas être le mieux adapté à cette question