Linux ბრძანებები სერვერის ადმინისტრატორისთვის: 40 მთავარი

სერვერის ადმინისტრირება ძირითადად ოთხი კითხვაა, რომელსაც ციკლში სვამ: რა მუშაობს, რას აკეთებს ის მანქანასთან, რა ჩაწერა ლოგში და ვის შეუძლია მასთან მისვლა. ამ კითხვებს დაახლოებით ორმოცი ბრძანება პასუხობს, და როცა ისინი თითებში გექნება, თვეობით არ დაგჭირდება ორმოცდამეერთე. ეს პოსტი სწორედ ამ ბრძანებებს აღწერს - იმ flag-ებთან ერთად, რომლებიც მათ სასარგებლოს ხდის, და იმ ხაფანგებთან ერთად, რომლებიც ძვირად უჯდება ადამიანს. ვგულისხმობთ Debian-ს ან Ubuntu-ს, რადგან VDS-ის უმეტესი იმიჯი სწორედ ესაა, თუმცა აქ ყველაფერი, apt-ის გარდა, ნებისმიერ თანამედროვე დისტრიბუტივზე ერთნაირად მუშაობს.

სანამ დანარჩენზე გადავიდოდეთ, ორი ჩვევა ღირს გამოსამუშავებლად. პირველი: man ls და ls --help საძიებო სისტემაზე სწრაფია და ისინი აღწერენ იმ ვერსიას, რომელიც შენ გაქვს და არა იმას, რომელიც ნაპოვნი სახელმძღვანელოსია. მეორე: დააჭირე Ctrl-r და დაიწყე აკრეფა, რომ shell-ის ისტორიაში უკან მოძებნო. ის, რაც დღეს უნდა გაუშვა, უმეტესად გასულ კვირას უკვე გაუშვი.

ყოველდღიური ათეული#

ესენი ისეთი ბრძანებებია, რომლებსაც ფიქრის გარეშე კრეფ. მარჯვენა სვეტის flag-ები ისწავლე და სამუშაო დღის უმეტეს ნაწილს დაფარავ.

მათ გვერდით რამდენიმე პატარაც არის. stat file ბეჭდავს უფლებებს, მფლობელს, ზომასა და სამივე დროის ნიშნულს, რაც წყვეტს კამათს იმაზე, მართლა შეიცვალა თუ არა კონფიგურაცია. file something გეუბნება, რა არის ფაილი სინამდვილეში და არა იმას, რასაც მისი გაფართოება ამტკიცებს - ასე აღმოაჩენ, რომ ვიღაცის ატვირთული "zip" RAR არქივია. nproc ბეჭდავს პროცესორების რაოდენობას, რომელიც მანქანას სჯერა, და ეს რიცხვი გჭირდება, რომ ამ პოსტში მოგვიანებით load average-ები ინტერპრეტაცია გაუკეთო.

ფაილებისა და ლოგების კითხვა#

სამუშაოს დიდი ნაწილი კითხვაა. მთავარი ხრიკი ისაა, რომ ყველაფერს არ კითხულობ.

$ tail -n 200 /var/log/nginx/error.log      # last 200 lines$ tail -F /var/log/nginx/error.log          # follow, survives rotation$ head -n 40 /etc/nginx/nginx.conf          # first 40 lines$ less +G /var/log/syslog                   # open at the end$ wc -l /var/log/auth.log                   # how many lines is this

tail -f ფაილს მისი გახსნილი handle-ით მიჰყვება. როცა ლოგების როტაცია ფაილს ქვემოდან სახელს უცვლის, -f აგრძელებს ისეთი ფაილის თვალყურის დევნებას, რომელსაც აღარავინ წერს, შენ კი ზიხარ და გჯერა, რომ სერვერი გაჩუმდა. tail -F ფაილს სახელით ხელახლა ხსნის და როტაციას უძლებს. გამოიყენე დიდი ასო.

ყველაფრისთვის, რასაც systemd მართავს, ხოლო თანამედროვე მანქანაზე ეს თითქმის ყველაფერია, ლოგი საერთოდ ფაილი არ არის:

$ journalctl -u nginx -f                    # follow one unit$ journalctl -u minecraft --since "30 min ago"$ journalctl -b -p err                      # errors since this boot$ journalctl -k                             # kernel messages only$ journalctl --disk-usage$ journalctl --vacuum-size=200M             # when the journal has grown

-u ირჩევს unit-ს, -b მიმდინარე ჩატვირთვით ზღუდავს, -p err პრიორიტეტით ფილტრავს, ხოლო --since იღებს უბრალო ინგლისურს, როგორიცაა "yesterday" ან "2026-09-20 18:00". კომბინაცია, რომელიც ინციდენტების უმეტესობას წყვეტს, არის journalctl -u <name> -b --no-pager | less, და შემდეგ ძებნა less-ის შიგნით. თუ სერვისი გეიმ სერვერია, საინტერესო სტრიქონები ჩვეულებრივ გაჩერებამდე ბოლო ოცდაათია და არა ბოლოში მდგომი stack trace. ლოგები, რომლებიც ღირს შენახვად აღწერს, რომელი მათგანია ღირსი, რომ მუდმივ ადგილას გადაიტანო.

შეკუმშულ არქივებში ძებნა მათი გახსნის გარეშეც შეიძლება. zcat, zless და zgrep .gz ფაილებზე ისე იქცევიან, როგორც მათი ჩვეულებრივი ვერსიები, ამიტომ zgrep "Invalid user" /var/log/auth.log.*.gz ერთ ჯერზე ორკვირიან როტირებულ ლოგებში ეძებს.

ძებნა: find, grep და which#

grep ფაილების შიგნით ეძებს. find ეძებს ფაილებს. ხალხი მუდმივად არასწორს იღებს ხელში.

$ grep -rn "listen" /etc/nginx/            # recursive, with line numbers$ grep -i "error" app.log | tail -n 50     # case-insensitive$ grep -c "404" access.log                 # count instead of printing$ grep -v "healthcheck" access.log         # everything except$ grep -B2 -A5 "Exception" app.log         # with context around each hit

-rn წყვილია, რომელიც უნდა დაიმახსოვრო: რეკურსიულად და სტრიქონების ნომრებით, ასე მიიღებ file:line: text ფორმატს და ფაილის გახსნა პირდაპირ სწორ ადგილას შეგიძლია. -B და -A ბეჭდავს სტრიქონებს დამთხვევამდე და მის შემდეგ, და სწორედ ესაა განსხვავება იმას შორის, იცოდე, რომ exception მოხდა, და იმას შორის, იცოდე, რომელმა მოთხოვნამ გამოიწვია.

$ find /home -type f -name "*.db" -size +50M$ find /var/log -type f -name "*.gz" -mtime +14 -delete$ find . -type d -name node_modules -prune -o -type f -name "*.js" -print$ which python3          # which binary will run$ command -v node        # the portable version of the same question

find წინადადებასავით იკითხება: სად ეძებო, რა ტიპის, რა სახელის, და შემდეგ რა გააკეთო. -mtime +14 ნიშნავს, რომ ფაილი თოთხმეტ დღეზე მეტია არ შეცვლილა. -delete საბოლოოა, ამიტომ ბრძანება ჯერ მის გარეშე გაუშვი და სია წაიკითხე. ეს ორი ნაბიჯი სიფრთხილის თეატრი არ არის; find ოდნავ არასწორი -name შაბლონით იმაზე მეტს იპოვის, ვიდრე ელოდი, დაახლოებით წელიწადში ერთხელ.

which პასუხობს კითხვას "რა გაეშვება სინამდვილეში, როცა ამას ავკრეფ", რაც მნიშვნელოვანია, როცა მეორე Node ან Python დააყენე და ძველი PATH-ში ისევ პირველია. თუ პასუხმა გაგაკვირვა, echo $PATH გაუშვი.

დატვირთულია თუ არა მანქანა: პროცესები, მეხსიერება და CPU#

ოთხი ბრძანება გეუბნება, არის თუ არა მანქანა პრობლემაში და როგორში.

$ uptime 14:22:01 up 12 days,  3:41,  1 user,  load average: 1.82, 1.44, 0.98$ free -h$ ps aux --sort=-%mem | head -n 12$ top          # or htop, if you installed it

load average სამი რიცხვია: ბოლო ერთი, ხუთი და თხუთმეტი წუთის. შეადარე ისინი nproc-ს. ორი vCPU-ს მქონე მანქანაზე 2.00 ნიშნავს სრულ დატვირთვას, 4.00 ნიშნავს, რომ სამუშაო რიგში დგას, ხოლო 0.8 - რომ ყველაფერი რიგზეა. მიმართულება ისევე მნიშვნელოვანია, როგორც მნიშვნელობა: 0.5 1.4 2.1 მანქანაა, რომელიც გამოკეთდა, ხოლო 2.1 1.4 0.5 მანქანაა, რომელსაც მალე ცუდი შუადღე ექნება. load ითვლის იმ პროცესებსაც, რომლებიც დისკს ელოდებიან, არა მხოლოდ CPU-ს, ამიტომ მაღალი load უქმი CPU-ებით ჩვეულებრივ ნიშნავს, რომ პრობლემა შენახვაშია და არა გამოთვლაში.

free -h ბეჭდავს სტრიქონს, რომელიც ძირითადად უნდა გაუშვა, და სვეტს, რომელიც არ უნდა გაუშვა. free სვეტი თითქმის ყოველთვის პატარაა, რადგან Linux თავისუფალ მეხსიერებას დისკის ქეშად იყენებს და მოთხოვნისთანავე აბრუნებს. რიცხვი, რომელიც გეუბნება, გაქვს თუ არა მეხსიერება, არის available. თუ available რამდენიმე ასეულ მეგაბაიტზე ნაკლებია, ერთი ცუდი გამოყოფის მანძილზე ხარ იქიდან, რომ ბირთვმა რამე მოკლას - ეს კი ცალკე თემაა: swap და OOM killer.

ps aux --sort=-%mem | head ყველაზე სწრაფი პასუხია კითხვაზე "რა ჭამს RAM-ს". %mem %cpu-ზე შეცვალე, რომ მეორე კითხვა დასვა. top ცოცხალი ვერსიაა; htop იგივეა ფერებით, ჩამოსქროლვითა და ხისებრი ხედით, და ის ოცდაათ წამს ნამდვილად ღირს, რაც მის დასაყენებლად გჭირდება. top-ის შიგნით დააჭირე M მეხსიერებით დასალაგებლად, P - CPU-ით, და 1 - თითო ბირთვის ჩვენების გასაშლელად.

როცა რამე უნდა გაჩერდეს:

$ kill 4821             # polite: SIGTERM, lets it clean up and save$ kill -9 4821          # SIGKILL: immediate, no save, last resort$ pkill -f "valheim_server"$ pgrep -af java        # find the PID and the full command line first

გეიმ სერვერებისთვის ეს განსხვავება აკადემიური არ არის. SIGTERM მათ უმეტესობას საშუალებას აძლევს, სამყარო დისკზე ჩაწერონ; SIGKILL კი გადაყრის ყველაფერს ბოლო ავტოშენახვის შემდეგ. -9 მხოლოდ მას მერე გამოიყენე, რაც თავაზიანი გაჩერება ერთი წუთის განმავლობაში ჩავარდა.

დისკის ადგილი და რამ შეავსო ის#

სავსე დისკი ყველაფერს არასასიამოვნოდ ამახინჯებს: მონაცემთა ბაზა ჩაწერაზე უარს ამბობს, ლოგი ჩერდება, სერვისი კი უკავშირო რამის შესახებ შეცდომით კვდება. რამე უცნაურის დებაგამდე ადგილი შეამოწმე.

$ df -h                        # space per filesystem$ df -i                        # inodes, when df -h says there is room$ du -sh /var/* 2>/dev/null | sort -h$ du -sh * | sort -h           # then descend into the biggest one$ ncdu /var                    # interactive, if you install it$ lsof +L1                     # deleted files still held open

du -sh * | sort -h და შემდეგ ყველაზე დიდ შედეგში cd - მთელი ტექნიკა ესაა. სამი-ოთხი გამეორება იმ დირექტორიაზე გიყვანს, რომელიც მნიშვნელოვანია. sort -h ადამიანისთვის წასაკითხ ზომებს სწორად ალაგებს, ამიტომ 2G 900M-ზე მაღლა დგას და არა ანბანით მის ქვემოთ.

ორი შემთხვევა, რომელიც მანამ ჯადოსნობას ჰგავს, სანამ არ იხილავ. პირველია inode-ების ამოწურვა: df -h 40%-ს აჩვენებს, ჩაწერა მაინც ვერ ხერხდება, df -i კი გვიჩვენებს, რომ inode-ების 100% წასულია, ჩვეულებრივ session-ების დირექტორიაზე ან ქეშზე, რომელიც მილიონობით პატარა ფაილს ინახავს. მეორეა წაშლილი ფაილი, რომელიც პროცესს ისევ გახსნილი აქვს. ადგილი არ ბრუნდება, სანამ ფაილის handle არ დაიხურება, ამიტომ du და df ერთმანეთს არ ეთანხმებიან. lsof +L1 ზუსტად ასეთ ფაილებს ჩამოთვლის; მათ მფლობელი პროცესის გადატვირთვა ადგილს მყისვე ათავისუფლებს. თითქმის ყოველთვის ეს ლოგის ფაილია, რომელიც ვიღაცამ დაცარიელების ნაცვლად წაშალა. გამოყენებაში მყოფი ლოგის სწორად დასაცარიელებელი გზაა truncate -s 0 /path/to/file და არა rm.

სერვისები და systemd#

ყველაფერი, რაც რებუთს უნდა გადაურჩეს, systemd-ს ეკუთვნის. საქმეს ხუთი ქვებრძანება ფარავს.

$ systemctl status nginx$ systemctl restart nginx$ systemctl enable --now fail2ban      # start it and start it at boot$ systemctl disable --now something    # stop it and stop it at boot$ systemctl daemon-reload              # after editing any unit file$ systemctl list-units --type=service --state=running$ systemctl list-timers$ systemd-analyze blame                # what made this boot slow

enable და start ცალკე იდეებია და მათი აღრევა systemd-ის ყველაზე გავრცელებული შეცდომაა. start მას ახლა უშვებს. enable აკეთებს იმას, რომ ჩატვირთვისას გაეშვას. სერვისი, რომელიც გაუშვი, მაგრამ არასოდეს ჩართე, გაქრება მანქანის პირველივე რებუთზე, ჩვეულებრივ თვეების შემდეგ, და ამ ორ მოვლენას არავინ აკავშირებს. --now ორივეს აკეთებს.

systemctl status მდგომარეობის ქვეშ ბოლო ათ სტრიქონს ბეჭდავს, რაც ხშირად საკმარისია იმის სანახავად, რატომ ჩავარდა გაშვება. როცა საკმარისი არ არის, დანარჩენს journalctl -u <name> -n 100 --no-pager გაძლევს. unit ფაილის რედაქტირების შემდეგ restart-მდე daemon-reload უნდა გაუშვა, თორემ systemd აგრძელებს იმ ვერსიის გამოყენებას, რომელიც ჩატვირთვისას წაიკითხა, შენ კი ისეთ ცვლილებას დებაგავ, რომელიც არასოდეს გამოყენებულა. თავად unit ფაილების წერა უფრო გრძელი თემაა და აღწერილია აქ: systemd სერვისები შენი აპებისთვის.

მომხმარებლები, უფლებები და მფლობელობა#

უფლებების შეცდომები "ჩემთან მუშაობს"-ის დიდ წილს შეადგენს. გამოსწორება თითქმის ყოველთვის მფლობელობაშია და არა რეჟიმში.

$ id                                   # who am I, and in what groups$ adduser deploy                       # interactive, creates the home dir$ usermod -aG sudo deploy              # note the -a; without it you replace groups$ sudo -u minecraft -i                 # become a service user for one session$ chown -R minecraft:minecraft /srv/minecraft$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys$ chmod +x start.sh

usermod -aG-ში -a ნიშნავს დამატებას (append). მისი გამოტოვება მომხმარებლის ყველა ჯგუფს იმ ერთით ცვლის, რომელიც დაასახელე, და სწორედ ასე იღებენ ადამიანები საკუთარ sudo წვდომას. ნელა აკრიფე.

რიცხვითი რეჟიმები სამნიშნაა - მფლობელისთვის, ჯგუფისთვის და დანარჩენებისთვის - სადაც კითხვა 4-ია, ჩაწერა 2 და შესრულება 1. ამიტომ 644 არის მფლობელს კითხვა და ჩაწერა, დანარჩენებს კითხვა; 755 ამატებს შესრულებას დირექტორიებისა და სკრიპტებისთვის; 600 მხოლოდ მფლობელისთვისაა. SSH უარს ამბობს პირად გასაღებზე ან authorized_keys ფაილზე, რომელსაც სხვაც კითხულობს, და უხმოდ პაროლის მოთხოვნაზე გადადის, ეს კი ყველაზე გავრცელებული მიზეზია, რის გამოც გასაღები "არ მუშაობს" - დანარჩენი ამ ამბისთვის იხილე SSH გასაღებები და გამაგრება.

სერვისები საკუთარი, არაპრივილეგირებული მომხმარებლით გაუშვი, თითო სერვისზე ერთი, და ფაილები ამ მომხმარებელს ეკუთვნოდეს. ეს დაყენებისას ერთ წუთს ჯდება და სწორედ ის განსხვავებაა, ერთი გატეხილი გეიმ სერვერი გექნება თუ გატეხილი მანქანა. როცა ამ მომხმარებლის სახელით მოქმედება გჭირდება, sudo -u minecraft -i მათ სახელზე login shell-ს გაძლევს და გამოსვლა არ გიწევს.

ქსელი: რა უსმენს და ვის შეუძლია მასთან მისვლა#

netstat მოძველებულია და მინიმალურ იმიჯებში არ არის. მისი ადგილი ss-მა დაიკავა და ის უფრო სწრაფია.

$ ss -tulpen                  # every TCP and UDP listener, with the process$ ss -tn state established    # current connections$ ip -brief addr              # the machine's addresses, one line each$ ip route                    # where traffic goes by default$ ufw status numbered         # what the firewall allows

ss -tulpen ამ პოსტის ყველაზე ღირებული ერთადერთი ბრძანებაა. გაუშვი იმ დღეს, როცა სერვერის მოწყობას ამთავრებ, და შემდეგ თვეში ერთხელ, ხოლო შედეგი მოკლე შეინახე. ყოველი სტრიქონი კარია. მონაცემთა ბაზა, რომელიც 127.0.0.1-ის ნაცვლად 0.0.0.0-ზეა მიბმული, პატარა სერვერების გატეხვის მეორე ყველაზე გავრცელებული გზაა, და ეს ბრძანება მას ხუთ წამში პოულობს. რა უნდა უყო კარებს, რომლებსაც იპოვი, ეს უკვე ufw firewall-ის გზამკვლევის და firewall-ის წესების, რომლებიც მნიშვნელოვანია საქმეა.

მანქანის გარედან შესამოწმებლად:

$ curl -I https://example.com                 # response headers only$ curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com$ dig +short A example.com @1.1.1.1           # ask a specific resolver$ ping -c 4 203.0.113.10$ mtr -rwc 50 203.0.113.10                    # 50 packets, report mode$ nc -zv 203.0.113.10 25565                   # is this TCP port open

dig საჯარო resolver-ზე @1.1.1.1-ით გაუშვი, როცა ჩანაწერი ახლახან შეცვალე, რადგან შენი საკუთარი resolver სავარაუდოდ ისევ ძველ პასუხს ინახავს TTL-ის ამოწურვამდე. nc -zv TCP-ს ამოწმებს; UDP გეიმ პორტს აზრიანად ვერ შეამოწმებს, რადგან არაფერია, რაც უარს დააბრუნებდა. mtr ანგარიშის სწორად წაკითხვა ცალკე უნარია, და latency, jitter და packet loss განმარტავს, რომელი სვეტია სინამდვილეში მნიშვნელოვანი.

გადაცემა, არქივები და დარჩენა დაკავშირებულად#

ფაილების მანქანაზე ატვირთვა და მისგან ჩამოტვირთვა და პროცესების გაშვებული დატოვება ტერმინალის დახურვის შემდეგ.

$ scp world.zip deploy@203.0.113.10:/srv/       # one file, quick$ rsync -avh --progress /srv/world/ backup:/srv/world/$ rsync -avh --delete src/ dest/                # make dest match src exactly$ tar -czf world-2026-09-21.tar.gz worlds_local/$ tar -xzf archive.tar.gz -C /srv/target/$ unzip plugins.zip -d plugins/

rsync scp-ს სჯობს ყველაფერში, რაც მეორდება, რადგან ის მხოლოდ შეცვლილს აკოპირებს და გაგრძელება შეუძლია. ბოლო დახრილი ხაზის წესი სწორედ ის ნაწილია, რომელზეც ყველა ებმევა: rsync -a src/ dest/ src-ის შიგთავსს dest-ში აკოპირებს, ხოლო rsync -a src dest/ ქმნის dest/src-ს. პირველად --dry-run-ით გაუშვი, განსაკუთრებით --delete-თან, რომელიც წაშლის ყველაფერს დანიშნულების ადგილას, რაც წყაროზე არ არის.

$ tmux new -s valheim         # new named session  Ctrl-b then d               # detach, leaving it running$ tmux attach -t valheim      # come back later$ tmux ls                     # what sessions exist$ watch -n 5 'ss -tn state established | wc -l'

tmux პროცესს ცოცხალს ინახავს მას შემდეგაც, რაც SSH სესია წყდება, და საშუალებას გაძლევს, იმავე ტერმინალს ნებისმიერი ადგილიდან ისევ მიუერთდე. ის სწორი ინსტრუმენტია გრძელი კომპილაციისთვის ან მიგრაციისთვის, რომელსაც უყურებ. ის არასწორი ინსტრუმენტია გეიმ სერვერის მუდმივად გასაშვებად: tmux-ში მყოფი პროცესი ჩატვირთვისას არ ირთვება, ჩავარდნისას თავიდან არ გაეშვება და უხილავია ნებისმიერი მონიტორინგისთვის, რომელსაც მოგვიანებით დააყენებ. ყველაფრისთვის, რაც ყოველთვის ჩართული უნდა იყოს, systemd unit გამოიყენე, tmux კი იმ სამუშაოს დაუტოვე, რომელსაც თვალს ადევნებ.

და ბოლოს, თავად სისტემის განახლებულად შენარჩუნება:

$ apt update && apt full-upgrade -y$ apt list --upgradable$ apt autoremove --purge$ needrestart                  # which services are running old libraries

apt update პაკეტების სიებს ანახლებს და არაფერს აუმჯობესებს, რაც ხვდება მათ, ვინც სხვა პაკეტ მენეჯერებიდან მოდის. full-upgrade არის upgrade პლუს უფლება, პაკეტი წაშალოს, როცა განახლებას ეს სჭირდება, და სწორედ ეს გინდა სერვერზე, რომლის განახლებულად შენახვასაც მართლა აპირებ. ბიბლიოთეკის განახლების შემდეგ გაშვებულ პროცესებს ძველი ასლი მეხსიერებაში რჩებათ, სანამ არ გადაიტვირთებიან; needrestart გეუბნება, რომელს. მთელი პირველი დღის რუტინა, თანმიმდევრობით, არის აქ: პირველი საათი ახალ VDS-ზე.

მართულ RE:NODE გეგმაზე ამათგან არაფერი გამოიყენება, რადგან ჰოსტზე shell-ს არ იღებ. სამაგიეროდ იღებ ფილტრის გარეშე კონსოლს ბრძანებების ისტორიითა და tab-ით შევსებით, რომელიც თამაშის ან აპის პროცესის საკუთარი შესვლა-გამოსვლაა და არა Linux prompt-ი, პლუს ბრაუზერში ფაილების მენეჯერსა და თითო სერვერის SFTP მონაცემებს. ეს კონფიგურაციას, ატვირთვებსა და ლოგების კითხვას ფარავს ზემოთ მოცემული არცერთი ბრძანების გარეშე. VDS მეორე გარიგებაა: სრული root წვდომა, და ამ გვერდზე ყველა ბრძანება შენი პასუხისმგებლობა ხდება. VDS-სა და გეიმ პანელს შორის არჩევანი რიცხვებით გიჩვენებს, რომელია შენს შემთხვევაში იაფი.

FAQ#

რა განსხვავებაა apt-სა და apt-get-ს შორის?

apt უფრო ახალი წინა ფენაა, განკუთვნილი ტერმინალში მაკრეფი ადამიანებისთვის, პროგრესის ზოლით და ოდნავ მეგობრული გამოტანით. apt-get-ს სტაბილური ინტერფეისი აქვს და სკრიპტებისთვისაა განკუთვნილი. ინტერაქტიული გამოყენებისას ისინი იგივეს აკეთებენ; გამოიყენე apt და ამაზე აღარ იფიქრო.

რატომ მეუბნება free -h, რომ თითქმის არ მაქვს თავისუფალი მეხსიერება?

იმიტომ, რომ Linux სხვაგვარად უქმ მეხსიერებას დისკის ქეშად იყენებს, და ეს კარგი რამაა. ქეშირებული მეხსიერება პროგრამის მოთხოვნისთანავე უბრუნდება. წაიკითხე available სვეტი და არა free, და იდარდე მხოლოდ მაშინ, როცა available პატარავდება.

როგორ გავაგრძელო პროგრამის მუშაობა გამოსვლის შემდეგ?

ყველაფრისთვის, რაც მუდმივია, გამოიყენე systemd unit Restart=on-failure-ით. ერთჯერადი სამუშაოსთვის, რომელსაც უყურებ, tmux ან nohup command &. განსხვავება ისაა, რომ systemd პროგრამას ჩავარდნის შემდეგ გადატვირთავს და რებუთის შემდეგ ისევ გაუშვებს, tmux კი არცერთს აკეთებს.

როგორ ვიპოვო, რომელი პროცესი იყენებს პორტს?

ss -tulpen ყველა მსმენელს ჩამოთვლის პროცესის სახელითა და PID-ით ბოლო სვეტში. თუ პორტი დაკავებულია და არაფერი ჩანს, სავარაუდოდ root არ ხარ - გაუშვი sudo-ით, რადგან პროცესის სვეტი სხვა მომხმარებლების პროცესებისთვის დამალულია.

მჭირდება თუ არა vim-ის სწავლა?

არა. nano თითქმის ყველა დისტრიბუტივზეა დაყენებული, მალსახმობებს ეკრანის ბოლოში აჩვენებს და კონფიგურაციის ფაილს შესანიშნავად არედაქტირებს. ისწავლე vim-იდან გამოსასვლელად საკმარისი - Esc და შემდეგ :q! - რადგან ის ზოგჯერ ნაგულისხმევი რედაქტორია, დანარჩენი კი გადადე, სანამ არ მოგინდება.

რა უნდა შევამოწმო პირველად, როცა სერვერი ნელია?

ამ თანმიმდევრობით: uptime load-ის nproc-თან შესადარებლად, free -h available სვეტისთვის, df -h სავსე დისკისთვის, და შემდეგ ps aux --sort=-%cpu | head. ეს ოთხი ერთად ოცი წამი გჭირდება და მიზეზს უმეტესად ამოიცნობს.