Puncte:0

Serviciul de rapoarte Systemctl a eșuat după ce utilizatorul a repornit manual Apache. Systemd și realitatea pot fi sincronizate fără a reporni procesele?

drapel ir

Am o instanță Apache care începe cu o unitate systemd. Un utilizator a oprit și a repornit manual instanța. Acum systemctl raportează serviciul ca „eșuat”. În afară de oprirea și repornirea Apache, există o modalitate de a face systemd să recunoască că serviciul rulează?

Acesta este starea. (Am încercat să ascund informațiile companiei, deci dacă httpd-apache și INT-1 nu are sens, este pentru că am eliminat o parte din șirul de caractere.)

$ systemctl status httpd-apache-int-1.service
* httpd-apache.service - Serverul Apache HTTP pentru Instanța INT-1
   Încărcat: încărcat (/usr/lib/systemd/system/httpd-apache-int-1.service; activat; prestabilit furnizor: dezactivat)
   Activ: eșuat (Rezultat: cod de ieșire) din miercuri 2022-05-04 15:56:39 CDT; 2 zile în urmă
     Documente: man:httpd(8)
           om:apachectl(8)
 PID principal: 26914 (cod=ieșit, stare=0/SUCCESS)

Acesta este fișierul meu de unitate.

$ systemctl cat httpd-apache-int-1.service
# /usr/lib/systemd/system/httpd-apache-int-1.service
[Unitate]
Descriere=Serverul HTTP Apache pentru instanța INT-1
După=network.target remote-fs.target nss-lookup.target
Documentation=man:httpd(8)
Documentation=man:apachectl(8)

[Serviciu]
Tip = bifurcare
# ExecStart nu este „modul sistem” de a face lucrurile.
# Pot exista probleme cu lucruri precum alergarea mai mult
# de un „systemctl ACTION httpd-apache-int-1”
#   la un moment dat. Dar folosind Environment(File) și
# systemd override pur și simplu nu fac ceea ce vreau.
ExecStart=/bin/sh -c '\
   sursa /etc/sysconfig/httpd.int-1; \
   sursa /opt/ca/webagent/ca_wa_env.sh ; \
   sursa /opt/apache/etc/int-1/WebAgent.conf ; \
   /usr/sbin/httpd $OPTIONS ; \
   ieșire 0'
ExecReload=/bin/kill -USR1 ${MAINPID}
ExecStop=/bin/kill -WINCH ${MAINPID}
# Vrem ca systemd să-i acorde lui httpd ceva timp pentru a termina cu grație, dar totuși vrem
# pentru a ucide httpd după TimeoutStopSec dacă ceva a mers prost în timpul
# oprire grațioasă. În mod normal, Systemd trimite semnal SIGTERM imediat după
# ExecStop, care ar ucide httpd. Trimitem SIGCONT inutil aici pentru a da
# httpd timp pentru a termina.
KillSignal=SIGCONT
PrivateTmp=adevărat

[Instalare]
WantedBy=multi-user.target

Acestea sunt procesele care rulează.

$ ps -ef | grep [i]nt-1
apache 1030 27237 0 14:30 ? 00:00:01 /usr/sbin/httpd -k start -f /opt/apache/etc/int-1/httpd.conf
apache 3291 27237 0 May05 ? 00:00:12 /usr/sbin/httpd -k start -f /opt/apache/etc/int-1/httpd.conf
apache 9974 27237 0 May05 ? 00:00:15 /usr/sbin/httpd -k start -f /opt/apache/etc/int-1/httpd.conf
root 27237 1 0 May04 ? 00:00:05 /usr/sbin/httpd -k start -f /opt/apache/etc/int-1/httpd.conf
apache 27239 1 0 May04 ? 00:07:00 LLAWP /opt/apache/etc/int-1/WebAgent.conf -APACHE24
apache 27261 27237 0 May04 ? 00:00:41 /usr/sbin/httpd -k start -f /opt/apache/etc/int-1/httpd.conf
apache 27262 27237 0 May04 ? 00:00:37 /usr/sbin/httpd -k start -f /opt/apache/etc/int-1/httpd.conf

Alte informatii care ar putea fi utile.

Apache
Versiunea serverului: Apache/2.4.6 (Red Hat Enterprise Linux)

OS
Red Hat Enterprise Linux Server versiunea 7.9 (Maipo)

$ systemctl --version
systemd 219
user10489 avatar
drapel nc
răspuns scurt: Nu, dar l-ai putea ignora. Dar de ce să nu-l repornești?
Marco avatar
drapel in
Poate folosiți pidfile care monitorizează systemd?
Marco avatar
drapel in
S-ar putea ca, din cauza pornirii complexe a serverului apache, cumva, systemd nu poate găsi pid-ul corect al procesului principal apache (de exemplu, folosește pid-ul „/bin/sh”)?
iAmJeff avatar
drapel ir
@user10489 Sistem de producție. Repornirile trebuie să fie aprobate de părțile interesate. În ceea ce privește „Răspunsul scurt: Nu” Dang. Speram să existe un truc de sistem.
iAmJeff avatar
drapel ir
@Marco Fișierul pid este cel definit în httpd.conf, deci „ar trebui” să fie același. Îmi amintesc că am văzut că PID-ul se potrivea de fapt cu procesul man când făceam „ps -ef | grep [a]pache”
Marco avatar
drapel in
@iAmJeff systemd are propria sa gestionare a pid-ului. Monitorizează procesele de pornire și încearcă să găsească pid-ul. Acest lucru este complet independent de ceea ce este scris în orice fișier de configurare al httpd.Comparați pid-urile din `systemctl status httpd-apache-int-1` cu pid-ul httpd.
iAmJeff avatar
drapel ir
@Marco Ai dreptate! Privind datele din întrebarea mea, 26914 din ieșirea de stare nu se potrivește cu 27237 listat de ps. Nu există o modalitate ușoară de a sincroniza asta? (Nu vreau să editez spațiul de memorie al proceselor care rulează.)
Marco avatar
drapel in
Utilizați systemd într-un mod care nu funcționează. Se pare că ești încă blocat în gândirea `init.d`. Cel mai bine, scrieți un script `init.d` pentru asta și lăsați systemd să genereze restul.
iAmJeff avatar
drapel ir
@Marco "... lasă systemd să genereze restul." Aveți un link sau două cu instrucțiuni despre asta?
iAmJeff avatar
drapel ir
@Marco În ceea ce privește una dintre postările tale anterioare, poți partaja numele sau locațiile fișierelor pid pe care systemd le monitorizează?
Marco avatar
drapel in
Nu sunt un dezvoltator de systemd, nu cunosc detaliile interne. Systemd nu monitorizează fișierele pid, cu excepția utilizării opțiunii `PIDFile=`. Pentru fiecare script `init.d`, systemd generează intern un pseudo-serviciu pe care îl puteți gestiona cu `systemctl` în același mod ca serviciile native systemd (vezi `man systemd-sysv-generator`). Dacă creați servicii systemd complexe, trebuie să căutați în manualele systemd (https://www.freedesktop.org/software/systemd/man/). Pot crea un răspuns care să rezolve exact problema ta, dar mai bine să-l înveți pentru probleme viitoare.
Marco avatar
drapel in
În cel mai bun caz, trebuie să schimbați o linie: puneți `exec` în fața lui `/usr/bin/httpd`

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.