Valheim სერვერის ლოგი: გაშვება, შესვლები და შეცდომები

Valheim სერვერის ლოგი ერთადერთი ადგილია, სადაც სერვერი თავის თავს განმარტავს. ნაგულისხმევად ის სტანდარტულ გამოსავალზე გადის - ტერმინალში, პანელის კონსოლში, docker logs-ში ან systemd journal-ში - ხოლო -logFile /path/to/file.log მას ფაილში გადაამისამართებს. ჯანსაღი გაშვება მყარი თანმიმდევრობით იკითხება: Unity და Steam ინიციალიზდება, world იტვირთება ან გენერირდება, სერვერი რეგისტრირდება, crossplay სერვერზე კი ჩნდება ხაზი ექვსნიშნა join კოდით. ამის შემდეგ ყოველი მოთამაშე, ვინც უერთდება, მოკლე ხაზების კვალს ტოვებს თავისი ID-ით, პერსონაჟის სახელით და ბოლოს დახურული socket-ით. დანარჩენი უმეტესად ხმაურია. ეს პოსტი გასწავლის იმ რამდენიმე ხაზის პოვნას, რომელსაც მნიშვნელობა აქვს: ვერსიების შეუსაბამობა, არასწორი პაროლები, უარყოფილი ID-ები, წარუმატებელი შენახვები და დაკარგული ბიბლიოთეკები.

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

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

Valheim საკუთარ ლოგ-ფაილს არ ინახავს, თუ არ სთხოვ. -logFile-ის გარეშე გამოსავალი იქ მიდის, საიდანაც პროცესი გაეშვა:

-logFile Unity player-ის არგუმენტია და არა Valheim-ის, დიდი F-ით იწერება:

$ ./valheim_server.x86_64 -nographics -batchmode \    -name "Ravenhold" -port 2456 -world "Midgard" \    -password 'herring-barrel-42' -logFile /home/valheim/logs/valheim.log

გამოიყენე ყოველთვის, როცა გამოსავალი სხვაგვარად გაქრებოდა - უმეტესად Windows-ზე, სადაც გაშვებისას მომკვდარი სერვერი კონსოლის ფანჯარას და მასთან ერთად მიზეზსაც ატარებს. systemd-ზე ან Docker-ზე ჩვეულებრივ უმჯობესია გამორთული დატოვო, რადგან journal-ი და კონტეინერის runtime უკვე ინახავს გამოსავალს, ბრუნავს და დროის ნიშნულს უმატებს. ერთი დეტალი: -logFile-ისთვის მითითებული ფაილი შემდეგ გაშვებაზე, როგორც წესი, გადაიწერება. თუ სერვერი crash-ით დასრულდა, ფაილი restart-მდე დააკოპირე, თორემ ერთადერთი მტკიცებულება შემდეგ გაშვებასთან ერთად დაიკარგება.

კლიენტსაც საკუთარი ლოგი აქვს. Windows-ზე ის Player.log-ია საქაღალდეში %USERPROFILE%\AppData\LocalLow\IronGate\Valheim\. როცა მოთამაშე ამბობს, რომ ვერ უერთდება, მისი ლოგი და სერვერის ლოგი გვერდიგვერდ წაკითხული ჩვეულებრივ ერთ წუთში ხსნის საქმეს.

ნორმალური გაშვება, თანმიმდევრობით#

მუშა გაშვება გრძელ გამოსავალს აწარმოებს. ყველა ხაზი არ გჭირდება; გჭირდება ორიენტირების ცოდნა, რადგან იქ, სადაც ისინი წყდება, არის პრობლემა. ძლიერ შემოკლებით, ამ ხაზებს შორის ასობით ხაზის გამოტოვებით, გაშვება ასე გამოიყურება:

Fallback handler could not load library .../libdl.soLoad world: Midgard (Midgard)Zonesystem StartDungeonDB StartGame server connectedSession "Ravenhold" with join code 483920 and IP 203.0.113.10:2456 is active with 0 player(s)

ზემოდან ქვემოთ წაკითხვისას ეს ამბობს:

1. Unity ინიციალიზდა. ჯერ ქვესისტემებისა და გრაფიკული მოწყობილობის ხაზები მოდის. უგრაფიკო სერვერზე შეტყობინებები გრაფიკული მოწყობილობის არარსებობის შესახებ მოსალოდნელია.
2. Steam-ის game server API ჩაიტვირთა. მის გარეშე სერვერს მოთამაშეების ავტორიზაცია და სადმე რეგისტრაცია არ შეუძლია. Linux-ზე აქ წარუმატებლობა თითქმის ყოველთვის ნიშნავს, რომ steamclient.so ვერ მოიძებნა.
3. World ჩაიტვირთა ან შეიქმნა. ხაზი, რომელსაც უნდა დაეძებო, არის Load world: Midgard შენი world-ის სახელით. თუ ლოგი ახალი world-ის გენერირებაზე საუბრობს, როცა არსებულს ელოდი, -world-ის სახელი ფაილის სახელს არ ემთხვევა - დიდი ასოების ჩათვლით - და სერვერმა შენი ძველის გვერდით ახალი world შექმნა.
4. Zone system-მა და dungeon database-მა დაიწყო. ეს world-ის ჩატვირთვის შემდეგ მოდის; გაჩერება world-ის ჩატვირთვასა და ამ ხაზებს შორის დაზიანებულ world ფაილზე მიუთითებს.
5. სერვერი Steam-ს დაუკავშირდა და დარეგისტრირდა. "Game server connected" ან მსგავსი ნიშნავს, რომ backend-მა მიიღო. crossplay სერვერზე აქვე PlayFab-ის ხაზებიც ჩნდება.
6. სესიის ხაზი. crossplay სერვერზე ის join კოდს შეიცავს; ნებისმიერ სერვერზე ადასტურებს სახელს, მისამართს და მოთამაშეთა რაოდენობას.

მომწიფებულ world-ზე სხვაობა "Load world"-სა და სესიის ხაზს შორის ათეულობით წამი შეიძლება იყოს. ეს არის world ფაილის დისკიდან კითხვა და ზონის მონაცემების აგება, და ის world-ის ზომასთან ერთად იზრდება. მოთამაშეები, რომლებიც ამ დროს ცდილობენ შესვლას, იღებენ "Failed to connect"-ს, ამიტომაც პროცესების სიის მიხედვით "გაშვებული" სერვერი შეიძლება ჯერ მზად არ იყოს.

join კოდი და სესიის ხაზი#

-crossplay-ით გაშვებულ სერვერზე join კოდი ამგვარ ხაზში იბეჭდება:

Session "Ravenhold" with join code 483920 and IP 203.0.113.10:2456 is active with 0 player(s)

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

თუ crossplay სერვერი join კოდს არასოდეს ბეჭდავს, ის PlayFab-ში არ დარეგისტრირდა. ჩვეულებრივი მიზეზებია: სერვერი გარედან ინტერნეტს ვერ აღწევს, PlayFab-ის გათიშვა, ან გაშვება, რომელიც ადრე ჩავარდა და შეგიმჩნეველი დარჩა. ამასობაში Steam-ის მოთამაშეებს მაინც შეუძლიათ მისამართით შესვლა. relay-ის მხარეს განიხილავს Crossplay და Xbox მოთამაშეები.

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

შესვლის, შეერთებისა და გასვლის ხაზები#

ყოველი მოთამაშე, ვინც უერთდება, ამოსაცნობ თანმიმდევრობას ტოვებს. მხოლოდ Steam-ის სერვერზე ის დაახლოებით ასე გამოიყურება:

Got connection SteamID 76561198012345678Got handshake from client 76561198012345678Server: New peer connected,sending global keysGot character ZDOID from Sigrid : 1234567890:1

და როცა ტოვებენ:

Closing socket 76561198012345678

თითოეული ნაწილი რას გეუბნება:

• `Got connection SteamID ...` - ქსელური კავშირი მოვიდა. ეს პორტის გახსნილობისა და იმის ყველაზე ადრეული დასტურია, რომ მოთამაშე სწორ სერვერამდე მივიდა. თუ მოთამაშე ამბობს "Failed to connect" და მისთვის ეს ხაზი არასოდეს ჩნდება, პრობლემა მისამართშია, პორტში ან firewall-ში და არა Valheim-ის შიგნით.
• `Got handshake from client ...` - კლიენტმა თამაშის პროტოკოლით ილაპარაკა. ვერსიის, პაროლისა და სიების შემოწმებები აქ ხდება.
• `Got character ZDOID from Name : ...` - მოთამაშემ ყველა შემოწმება გაიარა და დაიბადა. ეს ხაზი გეუბნება, ვინ შევიდა რეალურად world-ში, პერსონაჟის სახელით. სწორედ ამ ხაზს უყურებენ შესვლის შეტყობინების სკრიპტები და Discord ბოტები.
• `Closing socket ...` - კავშირი დასრულდა, ნებისმიერი მიზეზით: ჩვეულებრივი გასვლა, crash, kick, timeout.

ამ პერსონაჟის ხაზში ZDOID 0:0 ცნობილი ნიშანია მოთამაშის სიკვდილისა და არა შესვლისა; ხელსაწყოები, რომლებიც შესვლებს Discord-ში აცხადებენ, მას გამორიცხავენ.

crossplay სერვერზე შეერთების ხაზებს პლატფორმის პრეფიქსიანი ID-ები აქვს - მაგალითად Steam_76561198012345678 ან Xbox_... - და PlayFab socket-ის ხაზები, ჩვეულებრივი SteamID-ის ფორმა კი შეიძლება არ ჩანდეს. რა ფორმითაც ლოგი აჩვენებს, იმ ფორმა სჭირდება სიის ფაილებს. ეს მოთამაშის ID-ის პოვნის საიმედო გზაა adminlist.txt-ისა და permittedlist.txt-ისთვის: სთხოვე ერთხელ დაუკავშირდეს და ID ლოგიდან დააკოპირე. ფორმატებს განმარტავს სიის ფაილები.

გრძელი ლოგიდან ყველა შესვლის ამოსაღებად Linux-ზე:

$ grep "Got character ZDOID" valheim.log | grep -v ": 0:0"$ grep -E "Got connection|Closing socket" valheim.log | tail -n 40

ხაზები, რომლებიც უარყოფილ მოთამაშეს ხსნის#

როცა მოთამაშეს უარს ეუბნებიან, სერვერი მიზეზს ჩვეულებრივ ერთ ხაზში ამბობს მისი კავშირის ახლოს. ფორმულირება იცვლება; გამორჩეული ფრაზა - არა.

ვერსიის ხაზი ამ სიიდან ყველაზე სასარგებლოა, რადგან ორივე ნომერს ბეჭდავს - სერვერისას და კლიენტისას - და ხვდები, რომელი მხარე უნდა განახლდეს. Valheim-ის patch-ის შემდეგ ასეთი ხაზების ნაკადს ელოდე, სანამ სერვერი არ განახლდება, და მოდიანი სერვერი არ განაახლო, სანამ მისი მოდები არ განახლებულა. დროებს განიხილავს სერვერის განახლება და ვერსიის შეუსაბამობა.

მოთამაშე, რომელიც handshake-მდე მივიდა და მერე უარი მიიღო, ამტკიცებს, რომ ქსელი წესრიგშია. მოთამაშე, რომელიც Got connection ხაზს არასოდეს ქმნის, სერვერამდე საერთოდ არ მისულა. ეს ერთი განსხვავება "ვერ ვუერთდები" თემების უმეტესობას წყვეტს; failed to connect შეცდომები კლიენტის მხარეს ყველა შეტყობინებას გადის.

შენახვები და პერიოდული სტატუსის ხაზები#

Valheim world-ს მეხსიერებაში ინახავს და ყოველ -saveinterval წამში წერს, ნაგულისხმევად 1800. ყოველი შენახვა ლოგში ჩანს:

World saved ( 412.5ms )

ფრჩხილებში მყოფი რიცხვი გვიჩვენებს, რამდენ ხანს გასტანა შენახვა, და ღირს მისი თვალყურის დევნება world-ის სიცოცხლის განმავლობაში. ახალი world ათეულობით მილიწამში ინახება; ძლიერ აშენებულ, ძლიერ გადაკეთებულ რელიეფიან world-ს ერთი წამი ან მეტი შეიძლება დასჭირდეს, რა დროსაც სერვერი ჭედავს. თუ მოთამაშეები ყოველ ნახევარ საათში ჩაკეტვას ან გათიშვას აღნიშნავენ, შეადარე ისინი შენახვის ხაზებს. გამოსავალი ჩვეულებრივ უფრო მოკლე ინტერვალია (მცირე, უფრო ხშირი შენახვა თითოეულზე ნაკლები ჯდება), ნაკლები მიმოფანტული ნივთები და ნაკლები რელიეფის გადაკეთება და არა უფრო დიდი გეგმა. უფრო გრძელ სიას იძლევა Valheim სერვერის წარმადობა და lag.

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

პერიოდულად სერვერი სტატუსის ხაზსაც ბეჭდავს, რომელიც ამის მსგავსია:

Connections 3 ZDOS:184211  sent:41 recv:122

Connections დაკავშირებული peer-ების რაოდენობაა. ZDOS არის world-ის ობიექტების რაოდენობა, რომლებსაც სერვერი აკონტროლებს - ყოველი ნაკეთობა, ნივთი, არსება და რელიეფის ცვლილება. ეს რიცხვი მხოლოდ იზრდება, როცა world შეისწავლება და შენდება, და კარგი მაჩვენებელია იმისა, რამდენად მძიმე გახდა world. ათიათასობით ნახტომი ჩვეულებრივ ნიშნავს, რომ ვინმემ უზარმაზარი ნაგებობა ააშენა ან ნივთების გროვა დაყარა.

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

Valheim-ის ლოგი უმეტესად ხმაურია და ზოგიერთი საგანგაშოდ გამოიყურება. მუშა სერვერზე ეს ნორმალურია:

• `Fallback handler could not load library ...` - Mono Linux-ზე ბიბლიოთეკებს ეძებს. უვნებელია და გაშვებისას ბევრჯერ მეორდება.
• თითქმის ყოველი შეტყობინების შემდეგ `(Filename: ... Line: ...)` ხაზები - Unity-ის debug-build-ის წყაროს მითითებები. უგულებელყავი; წაიკითხე ზემოთა ხაზი.
• Shader-ის, გრაფიკული მოწყობილობისა და აუდიოს გაფრთხილებები - dedicated სერვერს გრაფიკაც არ აქვს და ხმაც, Unity კი ამას აღნიშნავს.
• `Destroying abandoned non persistent zdo ...` და მსგავსი ZDO-ს დალაგება - სერვერი ობიექტებს ასუფთავებს, რომლებსაც არავინ ფლობს.
• Steam API-ის გაფრთხილებები, რომელსაც წარმატებული "connected" ხაზი მოჰყვება - პირველი მცდელობა ჩავარდა, განმეორებამ იმუშავა.

lloesche Docker image და რამდენიმე პანელის კონფიგურაცია ამ ხმაურის ნაწილს ნაგულისხმევად ფილტრავს. ეს ლოგს აადვილებს, მაგრამ რაიმეს გაფუჭებისას კონტექსტს შეიძლება მალავდეს, ამიტომ თუ პრობლემა აზრს არ იძენს, გაფილტრული გამოსავალი ნახე. ხმაურიანი ლოგების წაკითხვას იმ ერთი ხაზის გამოტოვების გარეშე ზოგადად განიხილავს თამაშის სერვერების ლოგები.

შეცდომის ხაზები, რომლებზეც რეაგირება ღირს#

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

ბოლოსწინა სტრიქონი მეორე დათვალიერებას იმსახურებს. პროცესი, რომელიც მეხსიერების ამოწურვის გამო მოკლეს, მშვიდობის სიტყვას ვერ წერს; ლოგი უბრალოდ სრულდება. თუ ლოგი მოულოდნელად წყდება და მანქანა ან პანელი იმ დროს მეხსიერებას ლიმიტზე აჩვენებს, ეს არის შენი პასუხი. RE:NODE-ზე სერვერი, რომელიც მეხსიერების ლიმიტს აღწევს, swap-ში დატოვების ნაცვლად ჩერდება და სუფთად გადაიტვირთება, ამიტომ შეწყვეტილი ლოგი მეხსიერების გრაფიკთან, რომელიც ჭერს ეხება, ზუსტად გეუბნება, რა მოხდა. გაშვების სრული სია არის პოსტში Valheim სერვერი გაშვებისას ვარდება.

ლოგების შენახვა და ძიება#

ლოგი, რომელშიც კვირის შემდეგ ძებნა არ შეგიძლია, დიდად არ გამოგადგება. რამდენიმე ჩვევა:

• systemd-ზე ამ საქმეს journal აკეთებს: journalctl -u valheim --since "2 hours ago" და journalctl -u valheim -g "Got character" კითხვების უმეტესობას ფარავს.
• `-logFile`-ით თავად დაატრიალე, თორემ ფაილი უსასრულოდ იზრდება. logrotate წესი copytruncate-ით მუშაობს პროცესთან, რომელიც ფაილს ღია ინახავს.
• Docker-ით დააყენე ლოგის ზომის ლიმიტები კონტეინერზე, რომ ბევრის მთქმელმა სერვერმა დისკი არ შეავსოს.
• განახლებამდე ან მოდის ცვლილებამდე გაითვალისწინე ბოლო ვერსიის ხაზი და შეინახე სუფთა გაშვების ლოგის ასლი. როცა რამე გაფუჭდება, შესადარებლად ცნობილად კარგი ლოგი ნებისმიერ გზამკვლევზე ძვირფასია.

RE:NODE-ზე ცოცხალი კონსოლი ფილტრის გარეშე გამოსავალს აჩვენებს, ქვემოთ ბრძანების ხაზით იმ ადმინ ბრძანებებისთვის, რომლებსაც ვანილა Valheim უშვებს, join კოდი კი ყოველი გაშვების შემდეგ იქ ჩნდება. ფაილების მენეჯერი და SFTP აღწევს ნებისმიერ ლოგ-ფაილს, რომელსაც -logFile-ით წერ. იმაზე უფრო ვრცელი განხილვისთვის, რა და რამდენ ხანს შევინახოთ, იხილე ლოგები, რომლებიც ღირს შენახვად.

FAQ#

სად არის Valheim dedicated სერვერის ლოგ-ფაილი?

ნაგულისხმევად ფაილი არ არის: ლოგი სტანდარტულ გამოსავალზე გადის - ტერმინალი, კონსოლის ფანჯარა, პანელის კონსოლი, journal ან docker logs. დაამატე -logFile გზით, რომ ფაილში ჩაიწეროს; ეს ერთადერთი გზაა მის შესანახად, როცა Windows-ის კონსოლის ფანჯარა იხურება.

როგორ ვიპოვო მოთამაშის ID ლოგში?

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

სად არის join კოდი ლოგში?

სესიის ხაზში, რომელიც -crossplay-ით გაშვებულ სერვერზე გაშვების შემდეგ იბეჭდება, სერვერის სახელისა და მისამართის გვერდით. ყოველ restart-ზე იცვლება, ამიტომ ყოველი მათგანის შემდეგ ხელახლა წაიკითხე.

რატომ აჩვენებს ლოგი ერთსა და იმავე სესიის ხაზს განმეორებით?

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

შემიძლია Valheim-ის ლოგის ხმაურის დამალვა?

ზოგი Docker image და პანელი გავრცელებულ ხმაურიან ხაზებს ნაგულისხმევად ფილტრავს, შენს მანქანაზე კი grep -v იგივეს აკეთებს. შეინახე ფილტრის გარეშე ასლი პრობლემების გასარკვევად, რადგან გაფილტრულმა გამოსავალმა შეიძლება შეცდომამდე ხაზი დამალოს.

რას ნიშნავს ZDOID 0:0 ლოგში?

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