Ты бы дистр и задачу конкретнее указал. В debian-based и rpm-based есть различия, да и вариантов настройки куча — под разный софт и требования.

В /var/log на запись же нет. А так есть. Ну и на чтение некоторых логов тоже прав нет. В общем, можешь там создать папку для себя и именно этой папке дать нужного владельца.

Те своей программой это сделать можна? или вначале руками создать?

Два варианта есть.

1 В начале от рута создайте каталоги и дайте на них разрешения. Дальше уже внутри этих каталогов можете своей программой делать то, что нужно. Но это, если честно, плохой вариант. Корявый.

2 Более предпочтительно, т.к. более правильно. Используйте демон syslog. Я пользуюсь syslog-ng, вполне рабочий вариант. Т.е., в Вашем приложении Вы можете отправлять записи в логи через этот демон. Нужно его будет правильно настроить. Настраивается как минимум фильтрация лог-записей от Вашего приложения в отдельный файл, чтоб не валить всё в кучу. man syslog-ng.

Вначале каталог для логов руками, конечно. Или скриптом установочным.

Наверное, и рассказать можете в чём же корявость первого варианта?

Могу.

Корявость в том, что это просто файлы. На локалхосте.

Syslog позволяет организовать протоколирование по сети. Это «раз». Т.е., это просто приятно — отлаживаемый демон где-то в сети, а логи на локальной машине. Приятно и в случае отладки и в случае продакшона, т.к. централизованного хранения логов ни кто не отменял. Можно, конечно, rsyncом собирать файло с разных машин, но... Нафига?

«Два». Т.к., систему протоколирования настраивать нужно, то гарантированно что не произойдёт ситуации, когда программист забыл отключить протоколирование в файлы и система со временем встала колом из-за переполнения файловой системы. Если по недосмотру сунули код в продокшон, забыв отключить в нём отладочные логи, то скорее всего ничего ужасного не произойдёт. Проблема будет обнаружена гораздо раньше, чем это произойдёт в случае, если демон фигачит тихо и молча в файло на каком-то локалхосте.

«Три». Есть уже разработанная подсистема. Её просто и тупо (там диссеров защищать ненужно) следует использовать. Есть даже (у меня по крайней мере) переходник для трансляции event log из-под оффтопика в syslog. Про нормально разработанный (грамотно по крайней мере) софт и не говорим. Циски, сетевые демоны, прикладное ПО, все считают что сислог есть, настроен и используется.

Ненужно рукоблудить лишнего. До добра не доводит.

Не соглашусь. Многим не надо раскидывать логи хз куда. Достаточно держать их на сервере. Может быть подключена библиотека логирования, которая и ротацию делает и всё подряд. Да и из под пользователя, под которым сервис запущен, можно будет логи читать. Так что depends.

Может быть подключена библиотека логирования, которая и ротацию делает и всё подряд.

А может быть не подключена. Одна из частых причин падения сервисов как раз таки несогласованность администрирования сервера с администрированием приложения.

Разработчик берет на себя логирование, при том что ему совершенно неизвестно на каком хосте и при каких ограничениях это приложение должно работать, как должно мониторится и где лежать. Потом разработчик забывает что он на себя это взял и то ли врубает debug лог, то ли ломает ротацию, то ли просто приложение переезжает на другой сервер с другими ограничениями, и получаем мину замедленного действия на проде.

Да и из под пользователя, под которым сервис запущен, можно будет логи читать.

Скорее всего journalctl это позволяет

я храню логи в /var/tmp/myprogramm

Может, поэтому и написал, что на самом деле там depends.

Только если сервис пользовательский.

Тут уважаемый alpha ответил...

Но я дополню. В нормально (по крайней мере грамотно настроенной) сети задачи протоколирования решаются проще, эффективнее и, что самое главное, единообразно. Чтобы избежать ненужной «беготни» с выяснением где и что и есть ли там вообще логи.

Поясню на примере. Есть сеть. В ней есть севера для продакшона и есть сервера и хосты разработчиков. Логично отправлять на основании северити левел записи с серверов в продакшоне на хост (пусть будет log-srv). А логи от разработки, с северити левел типа дебаг, на хост dev-log-srv. Тогда мы гарантированно не запутаемся где и какие логи искать.

Чтобы находить нужные сообщения быстро, я давно уже использую syslog-ng с бекэндом в бд. Для «боевых серверов» это постгрес, для дебага и sqlite хватает. В своё время я тестировал и syslog-ng и rsyslog, первый показал себя лучше. По крайней мере, не ложился от нагрузки с неск. тыс. обслуживаемых хостов, даже учитывая запись в постгрес.

Оно, конечно, можно туда ещё какую-никакую вебморду натянуть, но я смысла не вижу. Задача поиска нужного сообщения сводится к одному сиквел-запросу в бд. Гарантированно не запутаешься (мест для поиска всего два) и данные собираются со всей сети, т.к. логи охватывают всё — от ядра и до прикладного софта. Так же настроена система уведомлений. Если что-то прилетает в таблицы crit, alert, error, то админу летит e-mail и сообщение в jabber.

Важно здесь то, что всё (именно всё!) настраивается единообразно. Если нужно, то даже из скрипта на bash через logger можно сообщения кидать об отказе.

В таком случае и системы и разработка становятся более-менее упорядоченными. Вот как-то вот так.

syslog-ng с бекэндом в бд. Для «боевых серверов» это постгрес

И появляется единственная точка отказа для сотни сервисов?

В целом, я с тобой согласен. Но в частности, например, есть томкат, который и под виндой работает, и под линухами. Если у тебя одно приложение какое-то на сервере, то городить всю эту инфраструктуру не надо, ибо он сам что-то там логирует вполне сносно. Неудобно, конечно, в общем, но для данной задачи вполне. И ещё неизвестно нужна будет там такая инфраструктура или нет. И вот его дефолтные настройки пишут в файл. И всё нормуль. Поставил и работает. Не скажу, что переделка всего этого в сислог будет лучше. И тратить на это время с дефолта тоже смысла не вижу. Свои же приложения я в сислог пишу, потому что всё равно их под линуксом только планирую запускать и смысла не вижу тащить библиотеку и ещё потом правила для ротации настраивать и т.д. Короче, сильно depends от условий.

Так это же логи. А не сами сервисы.

Если сервис теряет возможность сообщить об ошибке, то может быть лучше ему завершиться.

Да.

Но бд у нас реплицируемая, так что страшно, но не сильно. Идеальных решений к сожалению нет. Это лучше (при наличии нормального оборудования) чем колхоз из сотни серверов.

Почему не использовать систему мониторинга на спец. базе под это заточенной? Типа influxBD?

Писец, читаешь тред и как будто на опеннет попал в окружение старпёров. Сначала напишут чушь собачью, а потом «но лучше так делать не надо». Гении просто. /rant

Если есть «папка-контейнер», типа сайт, то пишешь в нее/лог.тхт, если config.log == true. Если нет, или это обычный софт, то в syslog. Во фреймворках типа гтк/кут бывают встроенные средства, читай доки.

Если у тебя одно приложение какое-то на сервере, то городить всю эту инфраструктуру не надо, ибо он сам что-то там логирует вполне сносно

Ага, сносно.

Вот у меня как раз томкат падающий через два дня после деплоя и был, да. Что характерно два дня после деплоя обычно выпадают на воскресенье.

Да вот не знаю. :) Лучше пусть другой сервис скажет, что что-то не то с этим сервисом, чем нужный завершится.

Ну ты, может, поподробнее как-то опишешь? Что в итоге то было?

А смысла нет.

Я уже давно понял что системы мониторинга (которые кстати, тоже могут отказать и за ними тоже приглядывать надо), это для случая, когда стандартное протоколирование по-нормальному не осилили натянуть.

Если по-хорошему, то демон по идее, должен писать в нормальном состоянии всего две вещи — запущен и остановлен. Когда конкретно, чтобы у заказчиков вопросов не было. Ну максимум может написать ещё и о перезагрузке (конфиг например поменяли). Всё остальное при работе он писать не должен, если нет отказов. Если есть отказы, то вот их-то он и должен писать, чтобы приняли меры. И так же точно со всем — от загрузки ядра и до состояния дисков в рейд-массивах. При таком подходе что-то сверху изобретать смысла особо нет.

Выделили ещё один лог-файл и некорректно сконфигуровали ротацию логов. На стороне разработки не верифицировали, поскольку дев-инстанс в среднем живет не более пяти часов и никто не считает сколько и чего он генерит.

А админы деплоят сервис как черный ящик не глядя.

В облачном мире сервис хотя бы рестартовал с нуля автоматом с потерей всего, а в old-school - рестарт не помогает поскольку место-то всё так же занято.

А как быть в ситуации, когда демон упал, не успев записать в лог? Кто отследит его падение?

Это как раз, просто.

Если демон тихо помер, даже не пукнув в лог (хотя, с чего бы, если мы все аварийные ситуации отслеживаем), то это у нас явный отказ. Могут заволновался пользователи, т.к. часть системы не работает.

Чтобы этого не происходило можно проверять скриптом, по крону наличие запущенного демона. Это самое простое. Есть ещё вещи типа monit/Upstart, но я ими редко пользуюсь. Как правило, скриптов хватает.

Но сразу скажу — это практика так себе, не очень. По-хорошему, конечно, демон должен умудряться докладывать о проблемах и уметь восстанавливать свою работоспособность без перезапуска.

Ни чего про томкэт не скажу.

Не использовал его ни разу. Так... типа издалека видел. =)

Ну, в целом, понятно. ОК.