Puncte:2

Eroare la rularea systemd ca utilizator - Nu s-a putut conecta la magistrală: $DBUS_SESSION_BUS_ADDRESS și $XDG_RUNTIME_DIR nu au fost definite

drapel sr

Am un script care rulează ca rădăcină și încerc să seteze un serviciu de utilizator pentru a rula un daemon IPFS. Problema este că trebuie să activez serviciul ca utilizator, mai degrabă decât ca root. De obicei funcționează după o repornire, dar aș dori să evit asta dacă pot.

Scriptul de serviciu se află la ~/.config/systemd/user/ipfs.service

Contine:

[Unitate]
Descriere=daemon IPFS

[Serviciu]
# Environment="IPFS_PATH=/data/ipfs" # cale opțională către directorul init ipfs dacă nu este implicit (\$HOME/.ipfs)
ExecStart=/usr/local/bin/ipfs demon
Restart=la eșec

[Instalare]
WantedBy=default.target

(Am luat acest cod de aici: https://github.com/ipfs/go-ipfs/tree/master/misc )

Dacă rulez aceste comenzi ca utilizator, funcționează corect:

systemctl --user enable ipfs
systemctl --user start ipfs

Problema este că scriptul meu rulează ca root și nu îmi pot da seama cum să fac ca acesta să ruleze ca utilizator. Am incercat asta pana acum:

    # Activați linger pentru ca IPFS să poată rula la pornire
    loginctl enable-linger $USER_ACCOUNT

    # Activați serviciul să ruleze la pornire
    sudo -u $USER_ACCOUNT systemctl --user enable ipfs

    # Începeți serviciul acum
    sudo -u $USER_ACCOUNT systemctl --user start ipfs

Din păcate, cu aceasta, serviciul nu pornește și când primesc acest mesaj de eroare:

Nu s-a putut conecta la magistrală: $DBUS_SESSION_BUS_ADDRESS și $XDG_RUNTIME_DIR nu au fost definite (luați în considerare utilizarea [email protected] --user pentru a vă conecta la magistrala altui utilizator)

Odată ce scriptul s-a terminat și repornesc, serviciul începe bine, dar aș dori să evit ca utilizatorul să fie nevoit să repornească dacă pot. Orice ajutor ar fi apreciat.

Nate T avatar
drapel it
Contează unde rulează scriptul? Dacă răspunsul este nu, încercați să rulați de la un alt TTY. Uneori, acest lucru va funcționa atunci când pare că nu ar trebui. SystemD ar trebui să fie disponibil de oriunde. Este un shell de conectare, deci env. cerințele vor fi diferite. Sincer, nu știu dacă va funcționa sau nu, dar sunt curios.
drapel cn
În https://github.com/eriksjolund/user-systemd-service-actions-workflow/blob/main/.github/workflows/demo.yml#L18 a trebuit să adaug un `sleep 1` și `` XDG_RUNTIME_DIR=/ run/user/$UID`. Dacă rulați ca root, puteți încerca și `systemd-run --quiet --machine= $USER_ACCOUNT@ --user --collect --pipe --wait systemctl --user enable ipfs`
Puncte:0
drapel us

Aceste variabile sunt specifice utilizatorului. Acestea sunt setate de către instanța utilizatorului systemd atunci când un utilizator se conectează. Dacă scriptul dumneavoastră rulează ca un serviciu de sistem, atunci desigur că nu are acces la această variabilă pentru un anumit utilizator.

Dacă utilizați systemctl --user --global enable atunci serviciul va fi activat pentru toți utilizatorii.

Nate T avatar
drapel it
systemd nu este doar un binar în directorul bin. Este un sistem literal. Nu există cazuri specifice utilizatorului.
drapel us
Există două procese systemd. Primul este rulat ca /sbin/init și pornește serviciile globale. Al doilea este lansat atunci când un utilizator se conectează și pornește serviciile utilizatorului. Cele două variabile în cauză sunt stabilite de al doilea proces.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.