SSH სესია VPN-თან ერთად იღუპება: tmux თუ დავალებათა გამშვები?

თქვენი VPN ინდიკატორი მწვანდება, მარშრუტი ბრუნდება, და SSH ფანჯარა, რომელიც ღიად დატოვეთ, აღარასდროს აბრუნებს ბრძანების მაჩვენებელს. მარშრუტის აღდგენა არ აღადგენს იმ TCP საუბარს, რომელიც მას იყენებდა, ამიტომ ყველაფერი, რაც ამ ფანჯარაში აიკრიფა, დაკარგულია. თუ ნამდვილი შეშფოთება რედაქტორის ბუფერი ან ხანგრძლივი მიგრაციაა, გადაწყვეტა ისაა, რომ ეს სამუშაო აღარ მიაბათ ერთ კავშირს. tmux და დავალებათა გამშვები ამ პრობლემის სხვადასხვა ნახევარს ხსნიან.

ხელახლა დაკავშირებული VPN სოკეტს არ აგრძელებს

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

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

სამუშაო დისტანციურ ჰოსტზე განათავსეთ

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

ssh [email protected]
tmux new-session -s office-work

VPN-ის დაბრუნების შემდეგ გახსენით ახალი SSH კავშირი იმავე ჰოსტთან და ხელახლა დაუკავშირდით სახელით. მდგრადი ობიექტი სესიაა და არა კავშირი. მიეცით ისეთი სახელი, რომელსაც ერთი კვირის შემდეგაც იცნობთ.

tmux დავალებათა გამშვების წინააღმდეგ

tmux ინტერაქტიულ პროცესს ცოცხლად ინახავს, სანამ ჰოსტი ჩართულია. დავალებათა გამშვები ან სერვისების მენეჯერი არაინტერაქტიულ დავალებას ცოცხლად ინახავს, მისი გასვლის სტატუსს იწერს და SSH სესიის სრულ დასრულებას გადაურჩება. პირველი თქვენს მიერ დაკვირვებული სამუშაოსთვისაა, მეორე კი დაგეგმილი და მოგვიანებით შესამოწმებელი სამუშაოსთვის.

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

ორივე მიდგომას სჭირდება ჟურნალიც, რომელსაც ხელახალი დაკავშირების შემდეგ წაიკითხავთ. მის გარეშე იცით, რომ პროცესი არსებობს, მაგრამ არა რა გააკეთა. ჟურნალის ბილიკი სესიის სახელის გვერდით ჩაწერეთ.

გადაწყვიტეთ იმის მიხედვით, რაც უნდა გადარჩეს

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

systemd-run --user --unit=migrate-customers --collect ./migrate.sh

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