Tinyproxy-ის ჟურნალის როტაცია: რატომ არ არის maxsize 100M მკაცრი ზღვარი

maxsize 100M ჩანაწერი როტაციის გამომწვევია და არა Tinyproxy-ის ჟურნალის ფაილის მუდმივი ზღვარი. თუ logrotate დღეში ერთხელ ეშვება, ფაილი შემდეგ შემოწმებამდე 100 MB-ს გადააჭარბებს.

თუ Tinyproxy პირდაპირ LogFile-ში წერს, ჩასვით ასეთი პოლიტიკა მის არსებულ logrotate ბლოკში:

daily
maxsize 100M
rotate 7
compress
delaycompress

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

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

ხელახლა გახსნა ასრულებს როტაციას

ფაილის გადარქმევის შემდეგ Tinyproxy-მ უნდა ხელახლა გახსნას თავისი ჟურნალი. Tinyproxy ადასტურებს, რომ SIGUSR1 გადატვირთავს კონფიგურაციას და ხურავს და ხელახლა ხსნის ჟურნალის ფაილს, ასევე გადატვირთავს ფილტრების კონფიგურაციას. შეინარჩუნეთ შეფუთული დამხმარე, რომელიც უკვე ასრულებს სწორ მოქმედებას, ნაცვლად სიგნალის ან PID ფაილის მდებარეობის გამოცნობისა.

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

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