Wie kann ich Skripte automatisch ausführen, wenn Ubuntu gestartet wird, damit ich sie nach dem Start nicht manuell ausführen muss?

Abhängig davon, welche Art von Skripten Sie ausführen müssen. Für Dienste und dergleichen sollten Sie upstart verwenden . Aber für ein Benutzerskript sollten diese von gnome als Sitzungsskripte gestartet werden! Schauen Sie unter System> Preferences> Startup Applications nach.

Nebenbei bemerkt, wenn Sie einige Skripts für die Terminalanmeldung benötigen, können Sie diese der Datei .bash_login in Ihrem Ausgangsverzeichnis hinzufügen .

Für 14.04 und älter

Ein einfacher Befehl (der nicht ausgeführt werden muss) könnte einen Upstart-Job wie den folgenden verwenden:

start on startup
task
exec /path/to/command

Speichern Sie diese in einer .confDatei in /etc/init(wenn Sie es brauchen als root ausführen , wenn das System bootet) oder ~/.config/upstart(wenn Sie es als Benutzer ausgeführt werden, wenn Sie sich anmelden).

Ein Ansatz ist das Hinzufügen einer @ Reboot- Cron- Task:

1. Mit Running crontab -ekönnen Sie Ihren Cron bearbeiten.

2. Eine Zeile wie diese hinzufügen:

   @reboot /path/to/script
   

   Führt dieses Skript aus, sobald Ihr Computer hochfährt.

Wie wäre es, wenn Sie den Befehl hinzufügen /etc/rc.local? Sie müssen jedoch sudo-Zugriff verwenden, um diese Datei zu bearbeiten.

sudo nano /etc/rc.local

Für 15.04 und später:

Um einen (kurzlebigen) Befehl ¹ beim Start mit auszuführen systemd, können Sie eine systemd-Einheit des Typs verwenden OneShot. Erstellen Sie beispielsweise /etc/systemd/system/foo.serviceFolgendes:

[Unit]
Description=Job that runs your user script

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

[Install]
WantedBy=multi-user.target

Dann renne:

sudo systemctl daemon-reload
sudo systemctl enable foo.service

Im Wesentlichen konvertiert dies nur einen typischen Upstart-Job in einen systemd- Job (siehe Systemd für Upstart-Benutzer ).

Sie können mehrere Befehle aus derselben Servicedatei in mehreren ExecStartZeilen ausführen :

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

Der Befehl muss immer mit dem vollständigen Pfad angegeben werden. Wenn ein Befehl fehlschlägt, wird der Rest nicht ausgeführt. A -vor dem Pfad weist systemd an, einen Exit-Status ungleich Null zu ignorieren (anstatt ihn als Fehler zu betrachten).

Relevant:

• Arch Wiki Eintrag auf systemd
• man 5 systemd.service

Für Benutzersitzungen können Sie ~/.config/systemdstattdessen die Systemeinheit in erstellen . Dies sollte ab 16.04 funktionieren, jedoch nicht mit früheren Versionen von Ubuntu mit systemd (da diese noch Upstart für Benutzersitzungen verwendeten). Benutzersitzungseinheiten können mit den gleichen Befehlen wie bei Systemdiensten gesteuert werden, jedoch mit der --userhinzugefügten Option:

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

Shell-Syntax

Beachten Sie, dass systemd im Gegensatz zu Upstart die Exec*Befehle nicht über eine Shell ausführt. Es führt eine begrenzte Variablenerweiterung und mehrere (durch ;) getrennte Befehle aus , aber das war es auch schon, was die Shell-ähnliche Syntax betrifft. Wenn Sie etwas Komplizierteres wünschen, z. B. Umleitung oder Pipes, schließen Sie Ihren Befehl in sh -c '...'oder ein bash -c '...'.

¹ Im Gegensatz zu langlebigen Dämonen.

Es gibt verschiedene Möglichkeiten, Befehle automatisch auszuführen:

1. Das Upstart- System führt alle Skripte aus, von denen es eine Konfiguration im Verzeichnis findet /etc/init. Diese Skripte werden während des Systemstarts (oder als Reaktion auf bestimmte Ereignisse, z. B. eine Anforderung zum Herunterfahren) ausgeführt und sind daher der Ort, an dem Befehle ausgeführt werden, die nicht mit dem Benutzer interagieren. Alle Server werden mit diesem Mechanismus gestartet.

   Eine lesbare Einführung finden Sie auf: http://upstart.ubuntu.com/getting-started.html den Manpages man 5 initund man 8 initgeben Ihnen die vollständigen Details.

2. .gnomercJedes Mal, wenn Sie sich bei einer GNOME-Sitzung anmelden, wird automatisch ein Shell-Skript in Ihrem Ausgangsverzeichnis aufgerufen. Sie können dort beliebige Befehle eingeben. Umgebungsvariablen, die Sie in diesem Skript festlegen, werden von jedem Programm angezeigt, das Sie in Ihrer Sitzung ausführen.

   Beachten Sie, dass die Sitzung erst startet, wenn das .gnomercSkript beendet ist. Wenn Sie daher ein Programm mit langer Laufzeit automatisch starten möchten, müssen Sie es &an den Programmaufruf anhängen , um es von der laufenden Shell zu trennen.

3. Über die Menüoption System -> Einstellungen -> Startanwendungen können Sie festlegen, welche Anwendungen beim Start Ihrer grafischen Sitzung gestartet werden sollen (Ubuntu definiert einige davon vor) und diese nach Ihrem Geschmack hinzufügen oder entfernen. Dies hat fast den gleichen Zweck und Umfang des .gnomercSkripts, außer dass Sie die shSyntax nicht kennen müssen (aber Sie können auch kein shProgrammierkonstrukt verwenden).

$HOME/.config/autostart

• Dieser Speicherort enthält die Liste der Startanwendungen.
• .desktop Hier kann eine Datei abgelegt werden, die beim Start ausgeführt wird.

Beispiel für eine .desktopDatei:

Folgende .desktopDatei einfügen $HOME/.config/autostartund übergeben chmod +x:

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

Hier "</path/to/script>"wird mit Pfad zu Ihrem ersetzt script.sh
( in der Regel empfohlen, /usr/local/binso dass durch direkt sagen Befehl ausgeführt werden kann myscriptersetzt mit "</path/to/script>").

Beispielbeispiel von script.sh:

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

Ergebnis: Die .desktopDatei wird gestartet, von $HOME/.config/autostartder aus das Skript ausgeführt wirdExec=

Daher können Sie Ihr gewünschtes Shell-Skript beim Start ausführen!

Für einfache Dinge können Sie unter System-> Einstellungen-> Sitzungen einen Befehl hinzufügen , der auf den Speicherort Ihres Skripts verweist.

Alternativ können Sie es zu /etc/init.d/rc.local hinzufügen oder einen Upstart- Job ausführen, wenn es sich um ein Zeug auf niedrigerer Ebene handelt .

Weitere Informationen finden Sie unter https://help.ubuntu.com/community/UbuntuBootupHowto

cron Antwort implementiert anders als oben gewählt

Diese Antwort verwendet immer noch croneine andere Methode als die Antwort mit der höchsten Bewertung. Dies funktioniert seit Ubuntu 16.04, wird aber wahrscheinlich viel früher unterstützt. Es ist nur so, dass ich angefangen habe cron, Jobs auszuführen, als der Computer seit dem 16.04 hochgefahren ist.

Wann läuft cron?

In Kommentaren fragte jemand "Wann laufen sie?". Sie können in Syslog / Journalctl sagen:

$ 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

Zu beachten ist , dass Sie per E- cronMail den Status der ausgeführten Jobs und der ausgeführten @rebootJobs erhalten können, sodass Netzwerkmanager und E-Mail erst ausgeführt werden, wenn Sie einen sleepBefehl in Ihre Skripts eingeben.

Wo sollen die Skripte abgelegt werden?

Legen Sie Ihre Skripte in das Verzeichnis /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

Wie sieht ein Skript aus?

Hier sind ein paar Skripte, die ich eingerichtet habe, um jeden Start auszuführen:

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

Sie sollten dazu upstart verwenden . Upstart wird für Ubuntu-Prozesse verwendet, die automatisch gestartet werden. Es ist eine erweiterte Lösung wie die alten System-V-init.d-Skripte. Sie können damit auch die Voraussetzungen für den Start Ihres Skripts festlegen (dh, muss das Netzwerk ausgeführt werden? Usw.).