Este sigur să ștergeți folderul cu binar pentru acest proces și pentru toate celelalte lucruri?
Da. Nu. Poate.
Depinde cu adevărat de modul în care vânzătorul a intenționat ca o aplicație să fie implementată și de ce a făcut un administrator când a instalat-o.
Unele aplicații (și toate dependențele lor) sunt într-adevăr implementate în propriul lor subdirector, care poate fi un singur director plat sau un subdirector mare, imitând adesea sistemul de fișiere rădăcină Linux convențional, de ex. cu un etc subdirectorul care conține fișiere de configurare, [s]bin pentru binare, a var subdirectorul care conține date etc etc.
Dacă nu ați implementat alte aplicații în același subdirector; ștergerea care va elimina complet aplicația.
Posibil ați ajustat configurația aplicației. Ajustările destul de tipice de făcut sunt schimbarea datelor persistente și a directoarelor de înregistrare în altă parte a sistemului dumneavoastră.
Cum pot identifica, unde este configurat pentru a fi pornit la pornire?
Destul de tipic de văzut sunt serviciile/procesele daemon pornite de systemd ca în exemplul de mai jos. În acest caz starea systemctl ar trebui să listeze fișierele unității și toate procesele începute de acestea și systemctl -a și alte comutatoare pot fi și ele utile.
Un instrument ca pstree poate fi destul de util pentru a vizualiza relațiile dintre părinți și copii și pentru a vedea ce proces a început. Când este folosit numai systemd, aceasta va da rezultate foarte asemănătoare cu starea systemctl dar atunci când sunt folosite alte mecanisme, acest lucru vă va oferi de obicei o perspectivă.
Apoi, există câteva metode mai „obscure”, de exemplu unora le place să folosească @reboot specificația cron timestamp pentru a avea servicii cron (re)pornire după o repornire.
pstree -a
systemd --switched-root --system --deserialize 22
ââ/usr/bin/spamd
â ââspamd copil
â ââspamd copil
ââagetty --noclear tty1 linux
ââatd -f
ââauditd
â ââ{auditd}
ââcronidă
ââcrond -n
ââdbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
â ââ{dbus-daemon}
ââdhclient -1 -q -lf /var/lib/dhclient/dhclient--eth0.lease -pf /var/run/dhclient-eth0.pid -H server eth0
ââporumbar
â âânicovala
â ââauth
â ââconfig
â ââimap
â ââimap-login
â ââlog
ââfail2ban-server -s /usr/bin/fail2ban-server -xf start
â ââ8*[{fail2ban-server}]
ââfirewalld -Es /usr/sbin/firewalld --nofork --nopid
â ââ{firewalld}
ââhttpd -DFORGROUND
â ââhttpd -DFORGROUND
â ââhttpd -DFORGROUND
â âârotatelogs -l /var/log/httpd/error_log.%Y.%m 86400
â âârotatelogs -l /var/log/httpd/access_log.%Y.%m 86400
ââmaster -w
â âânicovala -l -t unix -u
â ââpickup -l -t unix -u
â ââproxymap -t unix -u
â ââqmgr -l -t unix -u
â ââsmtpd -n smtp -t inet -u -o stress= -s 2
â ââtlsmgr -l -t unix -u
ââmms
â ââ85*[{mms}]
Procesul „master” din acea listă pstree este un bun exemplu. Acest nume ciudat de proces este de fapt postfix, fiind pornit din unitatea systemd postfix.service. Asta ar fi mai ușor de găsit în starea systemctl ieșire:
ââsistem.slice
ââpostfix.service
â ââ 1110 /usr/libexec/postfix/master -w
â ââ 1112 qmgr -l -t unix -u
â ââ 1121 tlsmgr -l -t unix -u
â ââ11508 pickup -l -t unix -u
ââserviciu.spamas-milter
â ââ1032 /usr/sbin/spamass-milter -g postfix -p /run/spamass-milter/postfix/sock
Ce altceva ar trebui să știu/să fac pentru a-l șterge în siguranță?
Identificați cum este pornit un serviciu și apoi oprirea acestuia este de obicei o primă abordare bună.
Apoi, obișnuiește-te să nu instalezi lucruri din sursă, ci să folosești manageri de pachete sau, de exemplu, să snap sau să rulezi un container.
