[Systemd] Demarrer un service après le boot (résolu)

[otacon]

Bonjour à tous,

Je cherche une solution pour demarrer un service après le boot. ce service étant long, il me mange 4 secondes de boot.
le service :

Code : Tout sélectionner

[Unit]
Description=Powertop tunings

[Service]
Type=oneshot
ExecStart=/usr/bin/powertop --auto-tune

[Install]
WantedBy=multi-user.target

Est-ce que dans le concept et les options disponibles je pourrais lancer ce service après la procédure de boot, "à temps perdu" et non dans la procédure imbriquée ?
Ce qui sous entendrai que WantedBy="rien", ce qui n'a plus aucun sens puisque le wantedby est nécessaire à l'option "enable" pour créer le lien symbolique.
Mettre une option After dans l'[Unit] déplace seulement le problème, puisque on a un point d'arrêt sur multi-user.target.

J'ai compris ou j'ai tout faux ?
Une idée ?

ceci dit, le service étant de type OneShot (lance puis oublie la commande), est-ce que finalement il ne serait pas plus simple de laisser tomber le service systemd et faire un simple fichier .desktop qui serait donc décorellé de la séquence de boot, de type :

Code : Tout sélectionner

[Desktop Entry]
Type=Application
Exec=sh -c "sleep 10 && (powertop --auto-tune &)"
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name[fr_FR]=Powertop
Name=Powertop
Comment[fr_FR]=
Comment=

Edit : par contre avec un fichier.desktop il ne se lancerai pas, puisque il faut lancer la commande en root. On revient donc au service systemd...

Vous en pensez quoi ?

[papajoke]

Bonjour

tu peux utiliser after ...

Code : Tout sélectionner

[Unit]
After=systemd-user-sessions.service

pour qu'il s’exécute en même temps que le gestionnaire de connexion ? (mais uniquement dans graphical.target ...)

Code : Tout sélectionner

After=display-manager.service
[Service]
ExecStart=/usr/bin/sleep 2

[otacon]

ne résoud pas le problême..

corrigé comme suit :

Code : Tout sélectionner

[Unit]
Description=Powertop tunings
After=gdm.service

[Service]
Type=oneshot
ExecStart=/usr/bin/powertop --auto-tune

[Install]
WantedBy=graphical.target

Code : Tout sélectionner

graphical.target @6.258s
└─multi-user.target @6.258s
  └─ModemManager.service @862ms +397ms
    └─basic.target @861ms
      └─sockets.target @861ms
        └─dbus.socket @861ms
          └─sysinit.target @859ms
            └─sys-fs-fuse-connections.mount @1.965s +2ms
              └─systemd-modules-load.service @283ms +9ms
                └─system.slice @279ms
                  └─-.slice @279ms

idée : si le service systemd lance un script, dans lequel je mets un sleep +20 secondes par exemple, est-ce que systemd rends la main au processus de boot après le lancement du script ou après la fin du script ?

[papajoke]

tu peux mettre le sleep dans l'unit :

Code : Tout sélectionner

[Service]
ExecStart=/usr/bin/sleep 10
ExecStart=/usr/bin/powertop --auto-tune

je ne comprend pas ta question systemd lance en // donc il "rend la main" dès le début . il faut utiliser systemd-analyze plot pour voir

[otacon]

Il donne l'info avec critical-chain, puisque on voit bien que powertop est caché dans le temps de graphical.target.
On a déclaré que powertop était demandé par graphical.target, ainsi graphical.target ne peut finir que quand powertop est fini (c'est ce que je comprends).
En ajoutant un sleep ici, tu augmente simplement le temps de résolution de graphical.target...

Résolu !
En utilisant Type=idle au lieu de oneshot :

Type=idle: systemd will delay execution of the service binary until all jobs are dispatched. Other than that behavior is very similar to Type=simple

donne :

Code : Tout sélectionner

graphical.target @1.241s
└─multi-user.target @1.241s
  └─ModemManager.service @904ms +337ms
    └─basic.target @902ms
      └─sockets.target @902ms
        └─org.cups.cupsd.socket @902ms
          └─sysinit.target @895ms
            └─systemd-timesyncd.service @870ms +25ms
              └─systemd-tmpfiles-setup.service @864ms +4ms
                └─local-fs.target @864ms
                  └─boot.mount @841ms +21ms
                    └─systemd-fsck@dev-disk-by\x2duuid-BA77\x2d4ED9.service @743ms +97ms
                      └─dev-disk-by\x2duuid-BA77\x2d4ED9.device @739ms

le service :

Code : Tout sélectionner

[Unit]
Description=Powertop tunings

[Service]
Type=idle
ExecStart=/usr/bin/powertop --auto-tune

[Install]
WantedBy=multi-user.target

et :

Code : Tout sélectionner

> sudo systemctl status powertop.service
● powertop.service - Powertop tunings
   Loaded: loaded (/etc/systemd/system/powertop.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since mer. 2015-08-12 11:59:52 CEST; 10min ago
  Process: 498 ExecStart=/usr/bin/powertop --auto-tune (code=exited, status=0/SUCCESS)
 Main PID: 498 (code=exited, status=0/SUCCESS)

août 12 11:59:47 arch powertop[498]: Loaded 341 prior measurements
août 12 11:59:47 arch powertop[498]: Devfreq not enabled
août 12 11:59:49 arch powertop[498]: unknown op '{'
août 12 11:59:52 arch powertop[498]: RAPL device for cpu 0
août 12 11:59:52 arch powertop[498]: RAPL Using PowerCap Sysfs : Domain Mask f
août 12 11:59:52 arch powertop[498]: RAPL device for cpu 0
août 12 11:59:52 arch powertop[498]: RAPL Using PowerCap Sysfs : Domain Mask f
août 12 11:59:52 arch powertop[498]: RAPL device for cpu 0
août 12 11:59:52 arch powertop[498]: RAPL Using PowerCap Sysfs : Domain Mask f
août 12 11:59:52 arch powertop[498]: Leaving PowerTOP