Démarrage automatique de Xorg
Mis à part les scripts de démarrage au niveau du système, votre environnement de bureau peut avoir sa propre façon d'exécuter des programmes automatiquement. Le dossier .config/autostartest censé être un moyen indépendant du bureau de définir les entrées d'exécution automatique. /etc/xdg/autostartest pour la configuration à l'échelle du système. Détails sur la spécification sur http://developer.gnome.org/autostart-spec/ .
Pour LXDE, les entrées de démarrage automatique peuvent également être définies dans ~/.config/lxsession/LXDE/autostart.
C'est un peu différent si vous devez exécuter vos scripts une fois le réseau opérationnel. Dans ce cas, vous devez vérifier les scripts spéciaux post-connexion qui peuvent être définis pour votre gestionnaire de réseau. Les deux NetworkManager et Wicd ont leurs propres façons de spécifier les entrées autorun post-connexion. Si le réseau est configuré via ifupdown, les scripts de post-up peuvent être placés dans le /etc/network/if-up.d/dossier. Mais une meilleure approche pour exécuter des scripts post-connexion pourrait être systemd (pour les systèmes qui le prennent en charge, ce qui est la majorité des distributions modernes).
Démarrage automatique en tant que service systemd
Si la chose que vous souhaitez démarrer automatiquement n'est pas une application graphique qui nécessite un bureau, il est préférable d'éviter d'utiliser les fonctionnalités de démarrage automatique fournies par xorg ou par votre environnement de bureau actuel.
systemd est devenu omniprésent dans de nombreuses distributions modernes, et il offre beaucoup de contrôle et de flexibilité en termes de démarrage et de fonctionnement de vos services.
Je vais résumer certains avantages ( systemd peut faire beaucoup plus ):
- Exécuter en tant qu'utilisateur root ou utilisateur spécifique: par exemple
User=myuser
- Redémarrez les services en cas d'échec avec des délais d'expiration configurables:
Restart=on-failure|on-watchdog|on-abnormal|always
- Définition du type de service:
Type=simple|forking|oneshot|notify|dbus
- Établissez les conditions préalables et les dépendances de démarrage, c'est-à-dire que vous pouvez configurer votre service pour qu'il démarre après la mise en place du réseau (
Wants=network-online.targetdans la [Unit]section).
Un exemple de service qui démarre un démon telegram-cli. Placez-le /etc/systemd/system/tg.service.
[Unit]
Description=MyDaemon
Wants=network-online.target
After=network-online.target
[Service]
ExecStart=/usr/local/bin/telegram-cli -k /etc/telegram-cli/tg-server.pub -W -P 1234 -d -vvvRC
ExecStop=/usr/bin/pkill -f telegram-cli
User=jicu
[Install]
WantedBy=multi-user.target
Vous pouvez maintenant activer le démarrage automatique du service:
sudo systemctl enable tg
Démarrez le service:
sudo systemctl start tg
Arrêtez le service:
sudo systemctl stop tg
Vérifiez l'état:
systemctl status tg
Désactivez le service:
sudo systemctl disable tg
Pour vous éviter de taper davantage, vous pouvez ajouter votre ~/.bashrcligne alias sc='sudo systemctl $*'puis vous pourrez raccourcir les commandes ci-dessus, par exemple sc start tg.
REMARQUE: si vous l'avez utilisé, cronsachez que les entrées crontab sont exécutées dans un environnement restreint - la même chose s'applique à systemd: utilisez toujours des chemins absolus et ne faites aucune hypothèse sur les variables définies. Définissez explicitement toutes les variables dont vos scripts dépendent. systemd n'utilisera pas votre utilisateur .bashrcet $PATH.
Plus d'informations: