Automatisch gestartete Programme gibt es seit jeher und bei jedem Betriebssystem. Da neu hinzukommende Autostart-Konzepte die bereits bestehenden nicht ablösen, sondern erweitern, ist der Überblick bei heutigen Systemen nicht mehr ganz einfach. Hier erklären wir alle wesentlichen Programmstarter, wobei wir uns mit Ubuntu und Linux Mint auf die verbreitetsten Linux-Systeme beschränken. Die meisten Punkte, insbesondere die zum Terminal und zu Cron, gelten auch für andere Linux-Distributionen. Ganz so leicht wie Windows-User haben es Linux-Anwender nicht. Aber dafür bekommen sie mächtige Instrumente an die Hand.
Startprogramme unter Ubuntu und Mint aufspüren
Die meisten Distributionen bieten ein grafisches Tool, um die automatischen Starts bequem zu verwalten – typischerweise mit dem Namensbestandteil „session“ (oder „Sitzung“ auf deutschem System). Unter Ubuntu und Mint heißt das Tool gnome-sessionproperties und ist auch über den lokalisierten Namen „Startprogramme“ im Hauptmenü erreichbar. Durch Deaktivieren des Häkchens schalten Sie dort ein Programm einfach ab, über die Schaltfläche „Entfernen“ verschwindet es komplett aus dem Verwaltungs-Tool (der Starter bleibt aber auf Dateiebene erhalten). Mit „Hinzufügen“ definieren Sie eigene neue Autostarts, wobei lediglich ein beliebiger Name und neben „Befehl“ der exakte Programmname einschließlich eventueller Parameter notwendig ist. Hier ist im Prinzip alles möglich: einfache Programmaufrufe, Aufrufe mit Schalter (etwa: „nautilus smb://server/transfer“), Starten von Shell-Scripts (mit komplettem Pfad, das sh-Script muss außerdem als „ausführbar“ markiert sein) oder auch der Start von Benutzerdateien:
soffice -calc smb://server/transfer/essentials.xls
Sie können Ihre Autostarts sogar mit Wartezeiten (Sleep-Kommandos) zeitlich staffeln:
sh –c "sleep 10;soffice -calc smb://server/transfer/essentials.xls"
Alle so definierten Autostarts gelten für den aktuellen Benutzer und werden in Form von .desktop-Dateien in dessen Home-Verzeichnis unter „~/.config/autostart“ gespeichert. Daher genügen für den Einsatz des Tools „Startprogramme“ normale Benutzerrechte. Die vom System benötigten Autostarts liegen ebenfalls in Form von .desktop-Dateien unter „/etc/xdg/autostart/“. Dazu gehören etwa der Schlüsselbunddienst oder das Soundsystem. Soll ein Programm unabhängig von der Benutzeranmeldung Benutzer gestartet werden, so hilft nur das manuelle Bearbeiten oder Erstellen eines Starters unter „/etc/xdg/autostart/“ mit root-Recht. Der Dateiname des Starters spielt keine Rolle, die Extension muss aber „.desktop“ lauten.
Als Modell können die bereits vorhandenen Klartextdateien dienen. Mindestens die folgenden vier Zeilen sind zwingend notwendig:
[Desktop Entry] Type=Application Name=[beliebig] Exec=[Programmbefehl]
Für „Exec“ gelten hier dieselben großzügigen Regeln wie beim Eintrag des „Befehls“ im grafischen Tool „Startprogramme“.
Tipp: Damit Ungeübte nicht versehentlich wichtige Komponenten aus dem Autostart entfernen, sind unter „Startprogramme“ die meisten Systemkomponenten weggefiltert. Dafür sorgt die Zeile „NoDisplay=true“ in der jeweiligen Desktop-Datei. Wenn das grafische Tool alle Autostarts zeigen soll, müssen Sie daher nur „NoDisplay“ auf „False“ stellen. In einem Rutsch erledigt das dieser Befehl
sudo sed -i 's/NoDisplay=true/NoDisplay=false/g' /etc/xdg/autostart/*.desktop
mit root-Rechten.
Tipp: Sollte ein Autostart mit einem komplexeren Befehl nicht korrekt funktionieren, hilft es meist, ein Bash-Script zwischenzuschalten. Das Script legen Sie am besten in einen Ordner, der sich im Systempfad („$PATH“) befindet, wie etwa „/usr/local/bin“. Das erfordert root-Recht. Danach müssen Sie das Script mit chmod +x datei.sh oder mit dem Midnight Commander ausführbar schalten.
Autostart checken via „.bashrc“ auf Linux-Servern
Die versteckte Datei „.bashrc“ liegt im Home-Verzeichnis jedes Benutzers und gilt folglich für den angemeldeten Benutzer. Alle dort enthaltenen Kommandos werden beim Start des Terminals abgearbeitet. Normalerweise dienen die „Bash Run Commands“ (bashrc) allein dem Terminal-Komfort mit Aliases, Functions, Prompt und Definitionen weiterer Variablen. Es ist auch sicher nicht praktikabel, jeden Terminal-Start mit diversen, eventuell sogar grafischen Programmen zu begleiten.
Etwas anders steht es auf Servern, die per SSH im Terminal verwaltet werden: Hier kann es durchaus sinnvoll sein, mit dem Start der Konsole auch gleich einen Dateimanager oder ein System-Tool wie htop zu laden. Ferner bietet es sich hier, die wesentlichen Serverfunktionen gleich mit der „.bashrc“ zu kontrollieren und gegebenenfalls zu korrigieren. Typische Frage wäre etwa, ob die angeschlossenen Laufwerke gemountet sind:
if mount -l | grep /sda1 > /dev/null; then echo "Drive 1 ist gemountet" else mount /dev/sda1 ~/sata1 fi
Wer mehrere Server betreibt, kann sich von der „.bashrc“ mit uname -a oder einem Tool wie inxi informieren lassen, auf welchem Gerät er sich befindet.
Tipp: Beim Start eines Terminals wird auch noch die Datei „.profile“ im Home-Verzeichnis berücksichtigt. Weil die hier enthaltenen Befehle genau wie jene in der „.bashrc“ für den angemeldeten Benutzer gelten, können Sie ebenso gut diese nutzen. Lediglich für die Startanalyse kann es wichtig sein, auch diese Startrampe zu kennen.
Terminalbefehle in der „rc.local“
Befehle, die unabhängig vom angemeldeten Benutzer in jedem Fall abgearbeitet werden sollen, können Sie auf Debian-basierten Systemen (Debian, Ubuntu, Mint, Raspbian) in der Datei „/etc/rc.local“ unterbringen. Diese Befehle werden schon vor der Benutzeranmeldung ausgeführt. Nur Abmelden und nachfolgendes Neuanmelden löst daher die „rc.local“ nicht aus. Um die Datei zu bearbeiten, benötigen Sie root-Recht:
sudo gedit /etc/rc.local
Vor der letzten Zeile „exit 0“, die bleiben muss, tragen Sie die gewünschten Kommandos ein. Grafische Programme scheiden an diesem Ort aus. Eingetragene Terminal-Befehle werden mit root-Recht ausgeführt und benötigen daher kein „sudo“. Eine Kennwortabfrage ließe sich bei der nicht interaktiven „rc.local“ sowieso nicht beantworten.
Bei Syntaxfehlern in der „rc.local“ steigt das Betriebssystem sofort aus und ignoriert einfach den Rest der Datei. Die Fehlersuche in der „rc.local“ ist daher schwierig, und empirisches Ausprobieren erfordert jeweils einen Rechnerneustart. Kommandos in dieser Startdatei sollten daher vorab genau getestet werden. Beachten Sie dabei, dass die Pfadvariable des Benutzerkontos zum Zeitpunkt der „rc.local“ noch nicht gilt und daher Programmaufrufe mit vollem Pfad anzugeben sind.
Der Taskplaner Cron - cleverer Helfer
Für zeitgesteuerte Programmstarts wie Sicherungen, Downloads oder Protokolle gibt es den Standarddienst Cron, der seine Jobs über die Textdatei „crontab“ erhält. Es gibt eine systemweite Datei „/etc/crontab“ für alle Benutzer, die nur mit Root-Rechten bearbeitet werden kann:
sudo crontab -e sudo gedit /etc/crontab
Beide Befehle führen zum Ziel, nur die Editoren unterschieden sich. Wenn Sie als normaler Benutzer crontab -e ohne „sudo“ eingeben, bearbeiten Sie die benutzerspezifische Crontab, die im Verzeichnis „/var/spool/cron/crontabs/[Benutzername]“ gespeichert wird. Im Allgemeinen sollte diese Benutzer-Crontab ausreichen. Manuelle Einträge (eine Zeile pro Job) in diese Textdatei sind etwas unhandlich, da sie zunächst die fünf Zeitangaben
Minute Stunde Tag Monat Wochentag
mit Leerzeichen oder Tabulatoren getrennt erfordert, nachfolgend den Programmbefehl. Ein Download, der jeden Tag um 9:00 Uhr erfolgen soll, und ein Backup, das täglich um 23:30 Uhr laufen soll, sehen dann etwa so aus:
0 9 * * * wget –q http://meineseite.de/meine.php 30 23 * * * /home/ha/backup.sh
Mit Hilfe folgender Syntax lassen sich auch grafische Programme starten:
0 10 * * * DISPLAY=:0 firefox
Das Format der Zeilen führt leicht zu unnötigen Fehlern – und das ist umso lästiger, als Fehler in der Crontab schwer zu debuggen sind, da schlicht nichts passiert, wenn eine Angabe inkorrekt ist. Um bei relativ einfachen Zeitangaben Formatfehler zu vermeiden, hat die Crontab einige simplifizierende Variablen eingeführt, die an Stelle der fünf Zeitabgaben akzeptiert werden. Die interessantesten sind „@reboot“ für Programmstarts bei der Anmeldung, ferner „@hourly“, „@daily“, und „@weekly“ (alle jeweils ohne Anführungszeichen).
Am besten schließen Sie aber Formatfehler einfach dadurch aus, dass Sie ein Hilfsmittel verwenden, das die Einträge für Sie übernimmt. Das bewährte gnome-schedule ist unter Debian-basierten Systemen (Debian, Ubuntu, Mint) mit
sudo apt-get install gnome-schedule
schnell nachinstalliert. Danach finden Sie das Tool im Startmenü oder Ubuntu-Dash als „Geplante Aufgaben“, oder Sie starten es mit gnome-schedule. Hier erstellen Sie durch Klick auf „Neu“ einmalige oder wiederkehrende Aufgaben. Zeitangaben sind in diesem Front-End deutlich einfacher als beim direkten Editieren der Cron-Tabelle. Für grafische Programme gibt es unter „Beschreibung“ und „Befehl“ den Dropdown-Eintrag „X-Anwendung“. Dabei nutzt gnome-schedule nicht die oben angesprochene Syntax mit dem „DISPLAY“-Argument, sondern den Umweg über ein Python-Script, wovon Sie sich leicht durch Editieren der eigentlichen Crontab überzeugen können. Mit gnome-schedule geplante Aufgaben laufen immer im Benutzerkontext; die entsprechende Konfigurationsdatei wird für jeden Benutzer im Verzeichnis „/var/spool/cron/tabs/“ gespeichert.
Die (komplizierte) Linux-Ergänzung Anacron
Cron startet Programme exakt zu den angegebenen Zeiten. Bei permanent laufenden Servern ist Cron daher absolut zuverlässig. Ist ein Gerät aber zum betreffenden Zeitpunkt abgeschaltet oder in einem Ruhezustand, wird der Job nicht ausgeführt: Ab 8:01 Uhr interessiert Cron keine Aufgabe mehr, die um 8:00 Uhr fällig gewesen wäre. Hier soll Anacron aushelfen: Der Dienst arbeitet anstatt mit festen Zeitangaben mit pauschalen Intervallen (täglich, wöchentlich) und arbeitet ab, was zu tun ist, sobald der Rechner läuft und Anacron feststellt, dass eine Aufgabe noch aussteht.
Dazu führt es Protokoll unter „/var/spool/anacron“. Die wesentliche Konfigurationsdatei von Anacron lautet „/etc/anacrontab“ und legt fest, welche Scripts (hourly, daily, weekly) überhaupt berücksichtigt und mit run-parts ausgeführt werden.
Die Scripts wiederum gehören in das passende Verzeichnis „/etc/cron.daily“ oder „/etc/cron.weekly“. Eine Reihe von Anacron-Jobs, insbesondere unter „/etc/cron.daily“, liegen bereits standardmäßig vor. Obwohl es sich dabei um normale Shell-Scripts handelt, haben diese Dateien keine Endung „.sh“. Dies ist wichtig und keine kuriose Einschränkung: Anacron-Start-Scripts dürfen keinen Punkt und somit keine Dateiextension enthalten.
Mit dieser komplizierten Bauanordnung ist Anacron reichlich fehleranfällig. Hinzu kommt ein interner Bug, der mindestens die stündliche Ausführung („hourly“) betrifft. Unterm Strich ist es zuverlässiger, Cron-Jobs mit kürzeren Zeitintervallen festzulegen und den Zeitpunkt so zu legen, dass das Gerät höchstwahrscheinlich läuft.
(PC-Welt/ad)