Puncte:0

Serviciul nu se conectează la journalctl

drapel in

Am un serviciu pentru utilizatori care este plasat sub /home/<user>/.config/systemd/user/<service>.service

Când performez systemctl --user status <serviciu> Am rezultatul dorit, de exemplu:

<utilizator>@<server>:~$ systemctl --starea utilizatorului <serviciu>
â <service>.service - Service
     Încărcat: încărcat (/home/<user>/.config/systemd/user/<service>.service; activat; prestabilit furnizor: activat)
     Activ: activ (în funcțiune) din marți 27-07-2021 10:23:34 UTC; acum 9 minute
   PID principal: 19059 (<serviciu>)
     CGroup: /user.slice/user-1008.slice/[email protected]/<service>.service
             ââ19059 /home/<user>/.local/share/<software>/install/active_release/bin/<software>-validator

Bușteni
Bușteni
Bușteni

Dar când încerci să vezi jurnalele complete cu journalctl --user -u <serviciu> -f Nu văd nimic, rezultatul este următorul:

<utilizator>@<server>:~$ journalctl --user -u <serviciu> -f
Nu au fost găsite fișiere jurnal.

Am această configurare care rulează pe o mulțime de alte servere cu exact aceeași configurație, dar acest lucru se întâmplă doar în acesta, care este unele servere de la Equinix, poate există o configurație diferită pentru journalctl în acest furnizor? Dar este important să subliniez că am instalat alte servicii în această mașină (nu cele pentru utilizatori, ci la nivel de sistem) și nu s-a întâmplat.

/etc/systemd/journal.conf este în configurația implicită.

Am văzut această postare ușor legată de problema mea: Linux journalctl nu este sincronizat cu starea systemctl / Journalctl nu se actualizează, am încercat să introduc StandardOutput=jurnal și StandardError=jurnal în secțiunea [Servicii], a făcut systemctl --user daemon-reload și am repornit serviciul, dar încă nu pot vedea niciun jurnal în journalctl.

De asemenea, mi-am verificat /varul pentru a valida dacă nu poate fi lipsă de spațiu pe disc, dar am destul de mult spațiu liber pe disc.

Serviciul meu este configurat astfel:

[Unitate]
Descriere=<Descrierea serviciului>
După=rețea.țintă
StartLimitIntervalSec=0

[Serviciu]
Tip=simplu
Restart=intotdeauna
RestartSec=1

EnvironmentFile=/home/<utilizator>/rpc.env

ExecStart=/home/<user>/bin/<service_script>.sh

#ExecStartPost=/usr/bin/taskset -a -p -c 5-23 28-47 $MAINPID
CPUAffinity=5-23 28-47

frumos=-10


LimitNOFILE=700000
LimitNPROC=700000

LogRateLimitIntervalSec=0
LogRateLimitBurst=0

WorkingDirectory=/home/<utilizator>/

[Instalare]
WantedBy=default.target

Aveți vreo idee cum o pot repara?

Michael Hampton avatar
drapel cz
Sintaxa corectă este `journalctl --user-unit .serviciu ...`
Daniel avatar
drapel in
Da, a funcționat perfect. Dar am folosit întotdeauna sintaxa `journalctl --user -u -f` și încă funcționează pe celelalte servere ale mele. Probabil că aceste noduri au venit cu toate cele mai recente pachete, iar într-o nouă versiune de systemd sintaxa de mai sus poate fi depreciată. Cea corectă este într-adevăr `journalctl --user-unit .serviciu` Mulțumesc

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.