SteamCMD-ის შეცდომები და მათი გამოსწორება: სახელმძღვანელო ადმინისტრატორებისთვის

SteamCMD-ის წარუმატებლობების უმეტესობა ხუთი მიზეზიდან ერთ-ერთზე დადის: ანგარიშს აპლიკაცია არ აქვს, დისკი სავსეა, მომხმარებელს საქაღალდეში ჩაწერის უფლება არ აქვს, ქსელი ჩამოტვირთვის შუა გზაზე გაწყდა ან Steam-ის ქეშირებული მონაცემები აპლიკაციის შესახებ მოძველებულია. შეცდომის ტექსტი ამ მიზეზებიდან ერთ-ერთს ასახელებს, თუმცა ხშირად ისე, რომ სხვა მიმართულებაში გიყვანს. ეს გვერდი იღებს შეტყობინებებს, რომლებსაც ადამიანები ნამდვილად ეძებენ, განმარტავს თითოეულის მნიშვნელობას და გასწორების გზას იმ რიგით გაჩვენებს, რა რიგითაც ღირს მათი ცდა. ვვარაუდობ, რომ ინსტალაციის საბაზისო ხაზი უკვე იცი. თუ არ იცი, SteamCMD explained განმარტავს app id-ებს, ანონიმურ შესვლას, validate-ს, beta ბრანჩებსა და განახლების სკრიპტებს. ეს პოსტი იმაზეა, რა უნდა გააკეთო, როცა ის ხაზი ვერ მუშაობს.

როგორ წაიკითხო SteamCMD-ის წარუმატებლობა#

წარუმატებელი app_update ორი სახის ხაზით სრულდება და ისინი სხვადასხვას გეუბნებიან.

ERROR! Failed to install app '896660' (Disk write failure)Error! App '896660' state is 0x202 after update job.

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

სანამ რამეს შეცვლი, სამი ფაქტი გაიგე:

1. სრული გამოტანა და არა ბოლო ხაზი. ზემოთ ასვლა. ჩუმად ჩავარდნილი შესვლა ან გაფრთხილება ინსტალაციის საქაღალდის შესახებ ხშირად იმ შეცდომიდან ორმოცდაათი ხაზით ზემოთაა, რომელსაც ყველა ციტირებს.
2. თავისუფალი ადგილი და inode-ები იმ ტომზე, სადაც ინსტალაცია მიდის. Linux-ზე df -h /srv/valheim და df -i /srv/valheim. სავსე inode-ების ცხრილი იგივე შეცდომას იძლევა, რასაც სავსე დისკი, მაშინ როცა df -h საკმარის ადგილს აჩვენებს.
3. ვინ არის ინსტალაციის საქაღალდის მფლობელი და ვინ უშვებს SteamCMD-ს. ls -ld /srv/valheim და whoami. თუ განსხვავდებიან, სავარაუდოდ პრობლემა იპოვე.

SteamCMD საკუთარ ლოგებსაც ინახავს თავისი Steam დირექტორიის ქვეშ - Linux-ზე ჩვეულებრივ ~/Steam/logs/, Windows-ზე steamcmd.exe-ს გვერდით მდებარე logs საქაღალდეში. იმ საქაღალდის content_log.txt ყოველ განახლების დავალებას კონსოლზე უფრო დეტალურად აღწერს, იმის ჩათვლით, თუ რომელი ფაილის ჩაწერა ვერ მოხერხდა. ზუსტი გზები იცვლება იმის მიხედვით, როგორ დაყენდა SteamCMD (დისტრიბუტივის პაკეტი სხვა home-ში ათავსებს ფაილებს, ვიდრე tarball), ამიტომ თუ ფაილი იქ არ არის, სადაც ელოდები, მოძებნე.

ერთი პარამეტრი ცვლის იმას, რასაც ხედავ. +runscript-ით გაშვებულ სკრიპტში @ShutdownOnFailedCommand 1 აიძულებს SteamCMD-ს, პირველივე შეცდომაზე გაჩერდეს. მის გარეშე წარუმატებელ app_update-ს მოჰყვება quit, პროცესი სრულდება და wrapper, რომელიც მხოლოდ exit კოდს ამოწმებს, წარმატებას აცხადებს. თუ შენს შეცდომებს მოთამაშეები პოულობენ და არა შენ, ჯერ ეს გაასწორე. Success! App 'X' fully installed.-ის grep-ის ჩვევა მთავარ SteamCMD პოსტშია განმარტებული, ხოლო კონსოლის კითხვა მოიცავს ზოგად უნარს, როგორ გამოარჩიო მიზეზი ხმაურისგან.

Missing configuration#

ERROR! Failed to install app '90' (Missing configuration)

ეს ყველაზე ხშირად საძიებელი SteamCMD შეცდომაა და ყველაზე ნაკლებად კონკრეტული. ის ნიშნავს, რომ SteamCMD-მ ამ აპლიკაციისთვის გამოსაყენებელი კონფიგურაცია ვერ მიიღო - ინფორმაცია იმის შესახებ, რომელი depot-ები უნდა ჩამოიტვირთოს ამ პლატფორმისა და ამ ანგარიშისთვის. მიზეზები, დაახლოებით ყველაზე ხშირიდან ყველაზე იშვიათისკენ:

• აპლიკაციის ინფორმაციის მოძველებული ქეში. SteamCMD ყველა აპლიკაციის მეტამონაცემს ინახავს თავის დირექტორიაში არსებულ appcache საქაღალდეში. როცა ეს ქეში არ ემთხვევა იმას, რასაც Steam ამჟამად აქვეყნებს, ინსტალაცია ჩავარდება, სანამ რამეს ჩამოტვირთავდეს.
• არასწორი app id. თამაშის id-ის მითითება იქ, სადაც dedicated server ხელსაწყოს id უნდა იყოს, ან შეცდომა, რომელიც სრულიად სხვა აპლიკაციაზე გადაგიყვანს.
• ანგარიში, რომელსაც ამ კონფიგურაციაზე წვდომა არ აქვს. აპლიკაციამ შეიძლება No subscription-ის ნაცვლად ეს შეტყობინება დააბრუნოს, როცა ანგარიში მის კონფიგურაციას ვერ ხედავს.
• პლატფორმა depot-ების გარეშე. ზოგი აპლიკაცია Invalid platform-ის ნაცვლად missing configuration-ს აცხადებს, როცა შენი ოპერაციული სისტემისთვის უბრალოდ build არ არსებობს.
• რაღაც დროებითი Steam-ის მხარეს. ასეც ხდება და ათი წუთის შემდეგ განმეორებული ცდა მუშაობს.

გამოსწორებები გაიარე თანმიმდევრობით:

1. გაუშვი იგივე ბრძანება ხელახლა. არა ცრურწმენის გამო - პირველმა გაშვებამ, რომელმაც აპლიკაციის ინფორმაციის ქეში განაახლა, ხშირად მეორე ცდაზე წარმატებას აღწევს.
2. შეამოწმე app id, რომ ეს იყოს სერვერის ხელსაწყოს id და არა თამაშისა. Valheim-ის სერვერი 896660-ია, თამაში 892970, და ინსტალდება მხოლოდ პირველი.
3. გააჩერე SteamCMD და წაშალე მისი appcache საქაღალდე (არა steamapps და არა შენი ინსტალაციის დირექტორია). შემდეგი გაშვება მას თავიდან ააგებს.
4. სცადე იძულებითი პლატფორმა, თუ აპლიკაცია მხოლოდ სხვა OS-ისთვის გამოდის - იხილე ქვემოთ.
5. თუ მას მფლობელი ანგარიში სჭირდება, შედი ასეთით.

$ cd ~/steamcmd$ rm -rf appcache$ ./steamcmd.sh +force_install_dir /srv/hlds +login anonymous \    +app_update 90 validate +quit

Half-Life Dedicated Server-ის განსაკუთრებული შემთხვევა

აპლიკაცია 90 - ძველი GoldSrc სერვერი, რომელსაც Counter-Strike 1.6 და სხვა Half-Life მოდები იყენებენ - ამ შეცდომით განთქმულია. წლებია არასანდოა და დიდი ხნის მოქმედი community-ის გამოსავალია, SteamCMD-ს app_set_config-ით უთხრა, რომელი მოდი გინდა, და შემდეგ რამდენჯერმე გაუშვა app_update 90 validate, სანამ წარმატებას არ დააფიქსირებს:

$ ./steamcmd.sh +force_install_dir /srv/cs16 +login anonymous \    +app_set_config 90 mod cstrike \    +app_update 90 validate +app_update 90 validate +quit

ქცევა დროთა განმავლობაში შეიცვალა და მოდის მიხედვით განსხვავდება, ამიტომ ეს აღიქვი როგორც რამ, რაც უნდა სცადო და არა გარანტია. თუ მხოლოდ მუშა CS 1.6 სერვერი გჭირდება, მზა ინსტალაცია უფრო ნაკლებ ტკივილს გაძლევს, ვიდრე აპლიკაცია 90-თან ჭიდილი - Counter-Strike 1.6 server guide აღწერს, რა სჭირდება სერვერს მას შემდეგ, რაც ფაილები ადგილზეა.

Invalid platform

ERROR! Failed to install app '556450' (Invalid platform)

ეს ორაზროვანი არ არის: აპლიკაციას არ აქვს build იმ ოპერაციული სისტემისთვის, რომელზეც SteamCMD მუშაობს. The Forest-ის dedicated server ჩვეული მაგალითია, რადგან მხოლოდ Windows-ის ბინარული ფაილი გამოდის. Linux-ზე Windows-ის build მაინც შეგიძლია ჩამოტვირთო და Wine-ით გაუშვა:

@ShutdownOnFailedCommand 1@sSteamCmdForcePlatformType windowsforce_install_dir /srv/theforestlogin anonymousapp_update 556450 validatequit

პარამეტრი app_update-მდე უნდა იყოს და ამ გაშვების დანარჩენ ნაწილზე მოქმედებს. Windows-ის სერვერის Linux-ზე გაშვება ცალკე გადაწყვეტილებაა თავისი ფასით; Linux vs Windows game servers ჩამოთვლის, რომელ თამაშებს სჭირდება ეს.

No subscription#

ERROR! Failed to install app '223350' (No subscription)

უფრო გასაგებია, ვიდრე ჩანს: შესული იდენტობა ამ აპლიკაციის ლიცენზიას არ ფლობს. ამ მდგომარეობამდე სამი გზა მიდის.

• ანონიმური შესვლა აპლიკაციაზე, რომელიც მას უარყოფს. DayZ (223350), Arma 3 (233780) და Project Zomboid-ის სერვერი ყველაზე ხშირი შემთხვევებია. გჭირდება Steam ანგარიში, რომელსაც თამაში ეკუთვნის.
• სწორი ანგარიში, არასწორი აპლიკაცია. ანგარიში, რომელსაც თამაში ეკუთვნის, მაგრამ ისეთ რამეს აინსტალებს, რისი ლიცენზიაც არ აქვს - ხშირად არასწორად აკრეფილი id-ის შედეგი.
• შესვლა, რომელიც რეალურად არ მომხდარა. თუ login ნაბიჯი ჩავარდა, მის შემდეგ ყველა ბრძანება არავის სახელით სრულდება და აპლიკაცია, რომელსაც მფლობელი სჭირდება, No subscription-ს აცხადებს. ადი ზემოთ და მოძებნე შესვლის ხაზი, რომელიც OK-ით მთავრდება.

გამოსწორება ისაა, რომ შედი ანგარიშით, რომელსაც თამაში ეკუთვნის, პირველად ინტერაქტიულად, რათა Steam Guard დაკმაყოფილდეს, და შემდეგ სკრიპტებშიც ეს ანგარიში გამოიყენო. გამოიყენე სათადარიგო ანგარიში, რომელშიც მხოლოდ ეს თამაშია: სერვერი ცუდი ადგილია იმ ანგარიშის მონაცემების შესანახად, რომლითაც ყიდულობ.

RE:NODE-ზე თამაშები, რომლებსაც შენი საკუთარი Steam ანგარიში სჭირდება - მათ შორის Arma 3, DayZ, Project Zomboid და 7 Days to Die - იქმნება დაუყოვნებლივ და შემდეგ Setup ტაბზე ელოდება, სანამ მონაცემებს შეიყვან. ისინი ინახება ისე, როგორც აკრიფე, ამიტომ სათადარიგო ანგარიშის რჩევა იქაც მოქმედებს.

Disk write failure და Missing file permissions#

ERROR! Failed to install app '896660' (Disk write failure)ERROR! Failed to install app '896660' (Missing file permissions)

ეს ორი სხვადასხვა შეტყობინებაა ერთმანეთს გადაფარავი პრობლემებისთვის და უფლებების პრობლემა შეიძლება ორივედ გამოჩნდეს. შეამოწმე ეს ოთხი რამ, ამ თანმიმდევრობით:

ადგილი ყველაზე ხშირი მიზეზია და ნაკლებად აშკარაა, ვიდრე ჟღერს. SteamCMD ჩამოტვირთულ ნაწილებს იმავე ტომზე ათავსებს, სანამ დააფიქსირებს, ამიტომ განახლებას არსებული ინსტალაციის გარდა შეცვლილი ფაილებისთვისაც სჭირდება ადგილი. დისკმა, რომელზეც 2 GB თავისუფალია, შეიძლება 1,5 GB-იანი განახლება ჩააგდოს. მას ჩვეულებრივ ავსებს ძველი Workshop კონტენტი, crash dump-ები და როტირებული ლოგები; what to do when the disk is full გაწმენდის სიას შეიცავს.

მეორე მფლობელობაა. კლასიკური გზაა, SteamCMD ერთხელ root-ით გაუშვა, "რომ ამუშავდეს", რაც root-ის საკუთრებაში მყოფ ფაილებს ტოვებს, რომელთა ჩანაცვლებაც სერვისის მომხმარებელს შემდეგ განახლებაზე არ შეუძლია. ერთხელ გაასწორე:

$ sudo chown -R steam:steam /srv/valheim /home/steam/steamcmd$ sudo -u steam /home/steam/steamcmd/steamcmd.sh \    +force_install_dir /srv/valheim +login anonymous \    +app_update 896660 validate +quit

შემდეგ აღარასოდეს გაუშვა root-ით. File permissions and ownership ზოგად შემთხვევას განიხილავს, იმ სერვერების ჩათვლით, რომლებიც ფაილებს სხვა მომხმარებლით წერენ, ვიდრე ის, ვინც აინსტალებს.

Windows-ზე ჩვეული მიზეზებია ინსტალაციის დირექტორია C:\Program Files-ის ქვეშ ამაღლებული უფლებების გარეშე, დაბლოკილი ფაილი, რადგან სერვერი ჯერ კიდევ მუშაობს, და ანტივირუსი, რომელიც ახლად ჩაწერილ executable-ს განახლების შუაში კარანტინში აგდებს. განახლებამდე გააჩერე სერვერი, დააინსტალე Program Files-ის გარეთ და ინსტალაციის დირექტორია real-time სკანირებიდან გამორიცხე, თუ ჩავარდნები ყოველთვის .exe და .dll ფაილებზე მოდის.

მდგომარეობის კოდები: 0x202, 0x402, 0x602 და სხვები#

Error! App '740' state is 0x602 after update job.

თექვსმეტობითი რიცხვი აპლიკაციის მდგომარეობის აღმწერი ფლაგების ერთობლიობაა, რომლებიც ერთმანეთს ემატება. იმის ცოდნა, რას ნიშნავს ბიტები, იდუმალ კოდს მარტივ წინადადებად აქცევს. ეს ფლაგებია, რომლებსაც ამ შეცდომებში შეხვდები:

კოდები ამ ცხრილის მიხედვით წაიკითხე:

• `0x202` = განახლება საჭიროა პლუს განახლება შეჩერებულია. დავალება შეჩერდა და აპლიკაციას განახლება ისევ სჭირდება. პრაქტიკაში ეს აბსოლუტურ უმრავლესობაში დისკის ადგილის პრობლემაა; სხვა რამემდე df -h შეამოწმე.
• `0x402` = განახლება საჭიროა პლუს განახლება დაწყებულია. დავალება დაიწყო და არ დასრულებულა. ჩვეულებრივი მიზეზია ქსელის შეფერხებები და timeout-ები.
• `0x602` = საჭიროა, შეჩერებულია და დაწყებულია. განახლება დაიძრა და შემდეგ შეჩერდა. ეს ზოგადი "განახლების შუაში რაღაც არასწორად წავიდა" მდგომარეობაა: დისკის ადგილი, უფლებები, გაწყვეტილი კავშირი ან მოკლული პროცესი.
• `0x6` = განახლება საჭიროა დაინსტალებულ აპლიკაციაზე, მიმდინარე განახლების გარეშე. ჩვეულებრივ ჩნდება, როცა დავალება დაწყებამდეც ვერ მივიდა - ამ გამოტანაში უფრო ადრე მოძებნე შესვლის ან აპლიკაციის ინფორმაციის ჩავარდნა.

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

იგივე ფლაგები manifest-ში ათობითი რიცხვის სახით ინახება. გახსენი steamapps/appmanifest_<appid>.acf ინსტალაციის დირექტორიაში და მოძებნე StateFlags. ჯანსაღი ინსტალაცია იკითხება როგორც "StateFlags" "4". ყველაფერი სხვა ნიშნავს, რომ SteamCMD ინსტალაციას დაუსრულებლად თვლის და შემდეგი app_update validate-ით სწორი ნაბიჯია.

ჩამოტვირთვის დროს პროგრესის ხაზები კოდების სხვა ნაკრებს იყენებს, რაც მათ მაძიებლებს ართულებს:

 Update state (0x5) verifying install, progress: 12.40 (512 / 4130) Update state (0x61) downloading, progress: 45.22 (1868 / 4130) Update state (0x101) committing, progress: 98.10 (4052 / 4130)

ეს ფაზებია და არა შეცდომები. წასაკითხი კოდის შემდგომი სიტყვაა. პროგრესის ხაზი, რომელიც downloading-ის დროს წუთების განმავლობაში ერთ რიცხვზე დგას, ქსელის ან დისკის გამტარუნარიანობის პრობლემაა; committing-ის ან verifying-ის დროს ნელ დისკზე ხშირად უბრალოდ ნელია, და მისი შეწყვეტით მიიღება 0x602.

Timeout-ები, კავშირის ჩავარდნები და შესვლის შეცდომები#

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

SteamCMD საკუთარ თავს ვერ ანახლებს. პირველ გაშვებაზე ან ხანგრძლივი შესვენების შემდეგ bootstrapper რამის გაკეთებამდე საკუთარ განახლებას ამოწმებს. თუ Steam-ის კონტენტ სერვერებამდე ვერ აღწევს, იქ ჩერდება შეტყობინებით, რომელიც დაახლოებით ასეთია: Steam needs to be online to update. შეამოწმე DNS-ის გარჩევა ჰოსტზე, გამავალი HTTP და HTTPS firewall-ის გავლით და proxy, თუ შენი ქსელი მას მოითხოვს. ხშირი დამნაშავეა ჰოსტი გატეხილი IPv6 მარშრუტიზაციით, მაგრამ მუშა IPv4 გზით.

შესვლა ეკიდება ან ვერ ხერხდება. შესვლის ხაზი მთავრდება OK-ით ან FAILED-ით მიზეზთან ერთად. ის, რასაც შეხვდები:

Logging in user 'spareaccount' to Steam Public...FAILED (Invalid Password)Logging in user 'spareaccount' to Steam Public...FAILED (Rate Limit Exceeded)Logging in user 'spareaccount' to Steam Public...FAILED (Two-factor code mismatch)

Invalid Password ზუსტად ის არის, რასაც ამბობს, თუმცა შეამოწმე, ხომ არ შთანთქა shell-მა სპეციალური სიმბოლო, თუ პაროლი ბრძანების ხაზში გადაეცი. Rate Limit Exceeded ნიშნავს, რომ მცირე დროში ძალიან ბევრი ცდა გაკეთდა; ერთადერთი გამოსავალი გაჩერება და ლოდინია, ხოლო ყოველი განმეორება ფანჯარას აგრძელებს. Two-factor code mismatch ნიშნავს, რომ Steam Guard-ის კოდი არასწორი ან ვადაგასული იყო, რაც მაშინაც ხდება, როცა ჰოსტის საათი გადაიწია. ერთი ინტერაქტიული შესვლა ხელით, მისი დადასტურება და იმის დაცდა, რომ SteamCMD მონაცემები ქეშში შეინახოს, ისაა, რითაც ავტომატური გაშვებები სამივეს თავიდან იცილებს.

ჩამოტვირთვები, რომლებიც timeout-ს აღწევს. დიდი აპლიკაციის განახლებები ხანდახან ჩერდება, Workshop-ის ჩამოტვირთვები კი timeout-ს გაცილებით ხშირად აღწევს:

ERROR! Timeout downloading item 463939057

დიდ Workshop ელემენტებს ნელ არხზე რეგულარულად ორი-სამი ცდა სჭირდება. სანამ რამეს ივარაუდებ, იგივე ელემენტი ხელახლა სცადე. თუ ერთი და იგივე ელემენტი ყოველ ჯერზე ვარდება, წაშალე steamapps/workshop/appworkshop_<gameappid>.acf და ელემენტის საქაღალდე, შემდეგ ისევ ჩამოტვირთე. განსხვავებული შეტყობინება, ERROR! Download item 463939057 failed (Failure)., უფრო ხშირად ნიშნავს, რომ ელემენტი კერძოა, წაშლილია ან მფლობელი ანგარიში სჭირდება. Steam Workshop mods on dedicated servers Workshop-ის მხარეს სიღრმისეულად მოიცავს.

Linux: 32-ბიტიანი ბიბლიოთეკები და steamclient.so#

SteamCMD Linux-ზე 32-ბიტიანი პროგრამაა. ახალ 64-ბიტიან სისტემაზე 32-ბიტიანი მხარდაჭერის გარეშე ჩავარდნა დამაბნეველია, რადგან ფაილი, რომელზეც ჩივის, აშკარად არსებობს:

steamcmd.sh: line 38: /home/steam/steamcmd/linux32/steamcmd: No such file or directory

"No such file" აქ ეხება 32-ბიტიან loader-ს, რომელიც ბინარულ ფაილს სჭირდება და არა თავად ბინარულ ფაილს. მეორე ჩვეული ფორმა ბიბლიოთეკას ასახელებს:

linux32/steamcmd: error while loading shared libraries: libstdc++.so.6:cannot open shared object file: No such file or directory

ორივე ერთნაირად სწორდება:

# Debian and Ubuntu$ sudo dpkg --add-architecture i386$ sudo apt update$ sudo apt install lib32gcc-s1      # lib32gcc1 on older releases$ sudo apt install lib32stdc++6     # if libstdc++.so.6 is still missing# RHEL, Rocky, AlmaLinux$ sudo dnf install glibc.i686 libstdc++.i686

პაკეტების სახელები დისტრიბუტივის გამოშვებებს შორის იცვლება, და ამიტომ არ ემთხვევა ერთმანეთს გზამკვლევები. თუ apt lib32gcc-s1-ს ვერ პოულობს, უფრო ძველ გამოშვებაზე ხარ, სადაც მას lib32gcc1 ჰქვია.

მსგავსი პრობლემა წარმატებული ინსტალაციის შემდეგ ჩნდება, როცა SteamCMD-ის ნაცვლად თამაშის სერვერი იწყება:

[S_API FAIL] SteamAPI_Init() failed; unable to locate a running instanceof Steam, or a local steamclient.so.

თამაშის სერვერი steamclient.so-ს ~/.steam/sdk64/-ში ეძებს (ან sdk32-ში 32-ბიტიანი სერვერისთვის) და ვერ პოულობს. SteamCMD ბიბლიოთეკას თავის linux64 და linux32 საქაღალდეებში აწვდის. მისი ადგილზე დაკავშირება სტანდარტული გამოსწორებაა:

$ mkdir -p ~/.steam/sdk64$ ln -sf ~/steamcmd/linux64/steamclient.so ~/.steam/sdk64/steamclient.so

ზოგი სერვერი ფაილს საკუთარი executable-ის გვერდით ელოდება და მათი გაშვების სკრიპტები LD_LIBRARY_PATH-ს ადგენენ, რომ ის იპოვონ. თუ თამაშის საკუთარი გაშვების სკრიპტი ამას აკეთებს, გამოიყენე ის და ბინარულ ფაილს პირდაპირ ნუ გაუშვებ.

შეტყობინებები, რომლებიც შეგიძლია უგულებელყო#

SteamCMD ხმაურიანია და რამდენიმე ხაზი ყოველ გაშვებაზე შეცდომას ჰგავს, თუმცა არაფერს ნიშნავს. მათი ცოდნა ერთ საღამოს გიზოგავს:

• Redirecting stderr to '.../logs/stderr.txt' - საინფორმაციოა.
• ILocalize::AddFile() failed to load file "public/steambootstrapper_english.txt". - ადრეულ გაშვებებზე იბეჭდება, უვნებელია.
• dlmopen steamservice.so failed: steamservice.so: cannot open shared object file - SteamCMD-ს ეს არ სჭირდება; Linux-ზე ყოველ გაშვებაზე იბეჭდება.
• Unable to determine CPU Frequency. Try defining CPU_MHZ. - კოსმეტიკურია, ხშირია კონტეინერებსა და VM-ებში.
• Please use force_install_dir before logon! - ამავე გზით უგულებელყოფადი არ არის. მიმდინარე build-ები აფრთხილებენ, როცა force_install_dir login-ის შემდეგ მოდის და ინსტალაცია შეიძლება იქ არ წავიდეს, სადაც გინდოდა. გადაიტანე პირველად.

მარტივი წესი: თუ გაშვება მთავრდება Success! App 'X' fully installed.-ით ან Success! App 'X' already up to date.-ით, ზემოთ მოყვანილი ხაზები ხმაური იყო.

როცა validate ასწორებს და როცა არა#

validate ინსტალაციის ყველა ფაილს Steam-ის manifest-თან ადარებს ჰეშით და ცვლის იმას, რაც არ ემთხვევა. ის ასწორებს:

• ინსტალაციას, რომელიც ნახევრად ჩაწერილი დარჩა სავსე დისკის, მოკლული პროცესის ან გაწყვეტილი კავშირის გამო - 0x602-ის ოჯახი;
• სერვერს, რომელიც "წარმატებული" განახლების შემდეგ გაშვებისთანავე ვარდება;
• დისკზე დაზიანებულ ფაილებს.

ის არ ასწორებს:

• ყველაფერს, რაც ზემოთ ჩამონათვალშია შესვლების, ლიცენზიების, პლატფორმებისა და app id-ების შესახებ - ის ამ შემოწმებების გავლის შემდეგ მუშაობს;
• დისკს, რომელიც ისევ სავსეა, ან დირექტორიას, სადაც მომხმარებელს ისევ ჩაწერა არ შეუძლია;
• გატეხილ მოდს, plugin-ს ან კონფიგურაციის ფაილს, რომელიც შენ დაამატე, რადგან ისინი manifest-ში არ არის. ამის ნაცვლად გამოიყენე what to do when a mod update breaks;
• კლიენტებთან ვერსიების შეუსაბამობას. ეს ბრანჩის საკითხია და განხილულია version pinning and rollbacks-ში.

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

როცა validate თავად განმეორებით ვარდება ერთსა და იმავე აპლიკაციაზე, სუფთა ხელახალ ინსტალაციამდე ბოლო გამოსავალია, ინსტალაციის დირექტორიაში წაშალო steamapps/appmanifest_<appid>.acf და განახლება ისევ გაუშვა. მაშინ SteamCMD-ს ინსტალაციის ჩანაწერი აღარ აქვს და ყველაფერს თავიდან ჩამოტვირთავს, ხოლო ფაილებს, რომლებიც აპლიკაციის ნაწილი არ არის, დატოვებს. ჯერ შეინახე backup-ები.

კონტეინერზე დაფუძნებულ ჰოსტზე კიდევ ერთი მიზეზი უნდა დავასახელო. თუ სერვერი ინსტალაციის ან განახლების დროს მეხსიერების ლიმიტს აღწევს, კონტეინერი ჩერდება და swap-ზე არ გადადის - RE:NODE-ზე ის სუფთად რესტარტდება - და რჩება ნახევრად ჩაწერილი ინსტალაცია 0x602-ის მსგავსი მდგომარეობით. განახლების validate-ით ხელახლა გაშვება მას ასწორებს. თუ ეს განმეორდება, გეგმა ამ თამაშის ინსტალაციის ეტაპისთვის ძალიან პატარაა; why your game server keeps restarting განმარტავს, როგორ გაარჩიო. პანელის კონსოლი SteamCMD-ის გამოტანას ხაზ-ხაზ აჩვენებს და დისკის გამოყენებას გეგმის ლიმიტთან მიმართებაში გრაფიკად გიჩვენებს, რაც ჩვეულებრივ საკმარისია იმის დასანახად, ზემოთ ჩამოთვლილი მიზეზებიდან რომელს წააწყდი; კონსოლის გზამკვლევი გაჩვენებს, სად არის.

FAQ#

"Missing configuration" ჩემი სერვერის პრობლემაა?

ჩვეულებრივ არა. ეს ნიშნავს, რომ SteamCMD-მ Steam-იდან ამ აპლიკაციისთვის გამოსაყენებელი კონფიგურაცია ვერ მიიღო - ყველაზე ხშირად აპლიკაციის ინფორმაციის მოძველებული ქეშის, არასწორი app id-ის ან დროებითი ჩავარდნის გამო. სცადე ერთხელ ხელახლა, შეამოწმე, რომ id dedicated server-ისაა და არა თამაშის, შემდეგ წაშალე appcache საქაღალდე SteamCMD-ის დირექტორიაში და ისევ გაუშვი.

რას ნიშნავს "state is 0x202 after update job"?

განახლება შეჩერდა, მაშინ როცა აპლიკაციას ის ისევ სჭირდება: ფლაგი 0x2 არის "განახლება საჭიროა", ხოლო 0x200 - "განახლება შეჩერებულია". პრაქტიკაში ეს თითქმის ყოველთვის დისკია, რომელზეც ჩამოტვირთვისას ადგილი ამოიწურა. გაათავისუფლე ადგილი ინსტალაციის ტომზე, დატოვე 20-30% მარაგი და გაუშვი განახლება validate-ით.

რატომ ამბობს SteamCMD "No subscription"-ს, როცა სერვერი უფასოა?

რადგან ამ თამაშის სერვერის ხელსაწყო ანონიმური შესვლებისთვის უფასო არ არის. DayZ-ს, Arma 3-სა და Project Zomboid-ს Steam ანგარიში სჭირდება, რომელსაც თამაში ეკუთვნის. იგივე შეტყობინება მაშინაც ჩნდება, თუ შესვლა გამოტანაში უფრო ადრე ჩუმად ჩავარდა, ამიტომ შეამოწმე, რომ შესვლის ხაზი OK-ით დასრულდა.

უნდა გავუშვა SteamCMD root-ით, რომ უფლებების შეცდომები აღარ იყოს?

არა. ეს შემდეგ განახლებას აჩავარდნებს, რადგან ფაილები, რომლებსაც ის წერს, root-ს ეკუთვნის და სერვისის მომხმარებელი მათ ვერ ანაცვლებს. გაუშვი SteamCMD იმავე ჩვეულებრივი მომხმარებლით, რომელიც სერვერს უშვებს, ერთხელ გააკეთე ინსტალაციის დირექტორიაზე chown ამ მომხმარებლისთვის და უფლებების შეცდომები შეწყდება.

შემიძლია უსაფრთხოდ წავშალო SteamCMD-ის appcache საქაღალდე?

დიახ. ეს აპლიკაციების მეტამონაცემების ქეშია, რომელსაც SteamCMD შემდეგ გაშვებაზე თავიდან ააგებს, და მასში არც თამაშის ფაილებია, არც შენახვები, არც მონაცემები. ნუ აგერევა ინსტალაციის დირექტორიაში არსებულ steamapps-თან, რომელიც აპლიკაციის manifest-სა და Workshop-ის ჩანაწერებს ინახავს.

როგორ გავასწორო SteamCMD ახალ 64-ბიტიან Linux ინსტალაციაზე?

ჩართე 32-ბიტიანი პაკეტები და დააინსტალე 32-ბიტიანი C და C++ runtime: Debian-სა და Ubuntu-ზე dpkg --add-architecture i386, შემდეგ apt install lib32gcc-s1 (ან lib32gcc1 ძველ გამოშვებებზე), და lib32stdc++6, თუ ისევ ჩივის. RHEL-ის ოჯახის სისტემებზე - glibc.i686 და libstdc++.i686.