Re: transmission-daemon и постоянные обращения к диску

2017-03-29 Пенетрантность Tim Sattarov 
On 29/03/17 11:22 AM, dimas wrote:
> а теперь самое интересное: если опцию -e (--log-file) вообще убрать, то сабж
> пишет в syslog, при этом не дергая диск, и вообще хорошо себя ведет.
> стало быть, механизм записи в файл где-то криво реализован.
> а может, кто подскажет, как syslog наладить, чтобы от сабжа записи в отдельный
> файл писал? должно быть как-то просто, но опять тыркаться, а вдруг кто-то 
> сразу
> знает, как правильно))
>
очень просто
в /etc/rsyslog.d/transmission.conf

if  $programname ==  'transmission-daemon' then /var/log/transmission.log
if  $programname ==  'transmission-daemon' then stop

И проверить, что строка

$IncludeConfig /etc/rsyslog.d/*.conf

находится над остальными правилами

Re: transmission-daemon и постоянные обращения к диску

2017-03-29 Пенетрантность dimas 
а теперь самое интересное: если опцию -e (--log-file) вообще убрать, то сабж
пишет в syslog, при этом не дергая диск, и вообще хорошо себя ведет.
стало быть, механизм записи в файл где-то криво реализован.
а может, кто подскажет, как syslog наладить, чтобы от сабжа записи в отдельный
файл писал? должно быть как-то просто, но опять тыркаться, а вдруг кто-то сразу
знает, как правильно))

Re: transmission-daemon и постоянные обращения к диску

2017-03-29 Пенетрантность dimas 
2017-087 17:53 Tim Sattarov  wrote:
> Проще нужно быть :)
> strace -p `pidof  transmission-daemon` -f -o stats
оу, спасибо! я не сильно вдумчиво ман курил, так-то да, оно, конечно, удобнее

> Интересно посмотреть на что указывает 3-й FD  в твоем случае ?
с логом в /dev/null
srv> ~$ ll /proc/11226/fd/[0-3]
lrwx-- 1 srv srv 64 мар 29 12:36 /proc/11226/fd/0 -> /dev/null
lrwx-- 1 srv srv 64 мар 29 12:36 /proc/11226/fd/1 -> /dev/null
lrwx-- 1 srv srv 64 мар 29 12:36 /proc/11226/fd/2 -> /dev/null
l-wx-- 1 srv srv 64 мар 29 12:36 /proc/11226/fd/3 -> /dev/null
с логом в файл - на него, как и положено:
srv> ~$ ll /proc/21183/fd/[0-3]
lrwx-- 1 srv srv 64 мар 29 12:59 /proc/21183/fd/0 -> /dev/null
lrwx-- 1 srv srv 64 мар 29 12:59 /proc/21183/fd/1 -> /dev/null
lrwx-- 1 srv srv 64 мар 29 12:59 /proc/21183/fd/2 -> /dev/null
l-wx-- 1 srv srv 64 мар 29 12:59 /proc/21183/fd/3 -> 
/var/log/transmission.log

Re: transmission-daemon и постоянные обращения к диску

2017-03-29 Пенетрантность dimas 
ничего интересного. анонсит раздачи на трекерах, к некоторым could not connect,
dht гоняет туда-сюда, ищет и находит пиров - в общем, нормальный ход вещей,
ничего необычного


2017-088 09:04 Илья  wrote:
> Может опция --log-debug покажет что то

Re: transmission-daemon и постоянные обращения к диску

2017-03-29 Пенетрантность dimas 
2017-088 10:07 Alexander Galanin  wrote:
> Он постоянно пишет в /var/lib/transmission-daemon/.config обновление
> DHT-таблицы, состояния торрентов. Может в этих файлах дело?

не-а. глянул find -mtime -1 -exec stat -c "%z %n" "{}" \; - dht.dat в 2 часа
обновился, resume-файлы в 8 и 11, stats.json вот сейчас (видимо, при вызове
transmission-remote -l), settings,json тоже в 2 часа.
в общем, явно не каждую секунду)) да и отправка лога в /dev/null однозначно
решает проблему, так что надо там копать

Re: transmission-daemon и постоянные обращения к диску

2017-03-29 Пенетрантность Alexander Galanin 
On Tue, 28 Mar 2017 22:08:31 +0300
dimas  wrote:

> поставил iotop, и сабж стал постоянно светиться в столбце "write". подумал,
> куда он там может пытаться писать

Он постоянно пишет в /var/lib/transmission-daemon/.config обновление
DHT-таблицы, состояния торрентов. Может в этих файлах дело?

-- 
Alexander Galanin

Re: transmission-daemon и постоянные обращения к диску

2017-03-29 Пенетрантность Илья 
Может опция --log-debug покажет что то

В Tue, 28 Mar 2017 22:08:31 +0300
dimas  пишет:


> подозрение: что-то в логи тоннами шлет. в syslog он не
> пишет, вроде как, а собственный его лог-файл я посмотрел -
> там несколько строчек всего, и ничего нового не появляется.
> в опциях стояло --log-error, именно так все и работало
> (несколько записей про одну раздачу, которая не найдена на
> таком-то трекере) однако же, после того как

Re: transmission-daemon и постоянные обращения к диску

2017-03-28 Пенетрантность Tim Sattarov 


On 28/03/17 05:17 PM, dimas wrote:
> однако же, поигрался тут еще по-всякому и нашел вот какую вещь: если запустить
> strace -p 5363,5364,5365,5385 -c &> stats
Проще нужно быть :)
strace -p `pidof  transmission-daemon` -f -o stats
> ну и так далее, каждую секунду он зовется и успешно синкает бедный диск. [1]
fsync вызывается толко на один filehandle. если он пуст то синкать
нечего и ничего не пишется.
Это как я понимаю fsync


Сейчас ещё раз посморел на вывод strace:

~# strace  -f  -p `pidof transmission-daemon`  2>&1 | grep fsync
[pid  1831] fsync(2)= -1 EINVAL (Invalid argument)
[pid  1831] fsync(2)= -1 EINVAL (Invalid argument)
[pid  1831] fsync(2)= -1 EINVAL (Invalid argument)
[pid  1831] fsync(2)= -1 EINVAL (Invalid argument)
[pid  1831] fsync(2)= -1 EINVAL (Invalid argument)
[pid  1831] fsync(2)= -1 EINVAL (Invalid argument)
^C


~# file /proc/1831/fd/2
/proc/1831/fd/2: broken symbolic link to socket:[27432]

lsof указывает на unix socket:

transmiss 1831 debian-transmission2u unix
0x9fe1d7728c00  0t0   27432 type=STREAM

то есть у меня обработкой вывода занимается systemd и мне пофиг, fsync
на unix socket  не работает.
однозначно бага

Интересно посмотреть на что указывает 3-й FD  в твоем случае ?

> [pid  5363] 00:01:24 fsync(3)   = 0

file /proc/5363/fd/3

Re: transmission-daemon и постоянные обращения к диску

2017-03-28 Пенетрантность dimas 
он плодит еще кучку потомков, для надежности запустил вот так:
strace -e open,write,close -o t-d.strace transmission-daemon \
--config-dir=.config/transmission-daemon/ -ep \
-e /var/log/transmission.log --log-error -f
выхлоп в аттаче. ничерта интересного. в лог пишет несчастную одну строчку.
шыштемд у меня нету, в syslog пару раз "closing session" выдал при остановке.

однако же, поигрался тут еще по-всякому и нашел вот какую вещь: если запустить
strace -p 5363,5364,5365,5385 -c &> stats
получаем примерно по одному fsync в секунду (см. файл stats)
далее, при логе в /var/log/transmission:
srv> ~$ strace -p 5363,5364,5365,5385 -e fsync -t
strace: Process 5363 attached
strace: Process 5364 attached
strace: Process 5365 attached
strace: Process 5385 attached
[pid  5363] 00:01:18 fsync(3)   = 0
[pid  5363] 00:01:20 fsync(3)   = 0
[pid  5363] 00:01:21 fsync(3)   = 0
[pid  5363] 00:01:22 fsync(3)   = 0
[pid  5363] 00:01:23 fsync(3)   = 0
[pid  5363] 00:01:24 fsync(3)   = 0
ну и так далее, каждую секунду он зовется и успешно синкает бедный диск. [1]
если же лог направить в /dev/null, общая картина та же, за исключением того,
что все эти fsync'и завершаются с ошибкой:
srv> ~$ strace -p 11226 -e fsync -t
strace: Process 11226 attached
00:09:30 fsync(3)   = -1 EINVAL (Invalid argument)
00:09:31 fsync(3)   = -1 EINVAL (Invalid argument)
00:09:32 fsync(3)   = -1 EINVAL (Invalid argument)
00:09:33 fsync(3)   = -1 EINVAL (Invalid argument)
00:09:34 fsync(3)   = -1 EINVAL (Invalid argument)
00:09:35 fsync(3)   = -1 EINVAL (Invalid argument)
вот она где собака порылась!
таким образом, имеем вот что: если лог-файл у нас на диске, то бешеная
программа каждую секунду упорно синкает этот самый диск! /dev/null тоже
пытается упорно синкать, но ему все равно))
видимо, где-то в коде, отвечающем за ведение логов, должно было быть что-то
типа: раз в секунду сбрасываем некий буфер (или как его правильно) в лог-файл и
синкаем диск, только из-за ошибки оно синкается независимо от того, писали мы в
файл или нет.


[1] http://man7.org/linux/man-pages/man2/fsync.2.html


2017-087 15:58 Tim Sattarov  wrote:
> я бы проверил ещё strace'ом, что он пишет и куда
> strace  -e write -p `pidof transmission-daemon`
> и вот сюда ещё:
> journalctl  -u transmission-daemon.service
> 
> у меня transmission-daemon из тестинга:
> 
> # apt-cache  policy transmission-daemon
> transmission-daemon:
>   Installed: 2.92-2
>   Candidate: 2.92-2
>   Version table:
>  *** 2.92-2 500
> 500 https://cloudfront.debian.net/debian unstable/main amd64
> Packages
> 400 https://cloudfront.debian.net/debian testing/main amd64 Packages
> 100 /var/lib/dpkg/status
> 
> 
> весь запуск и опции управляются через systemd:
> 
> [Unit]
> Description=Transmission BitTorrent Daemon
> After=network.target
> 
> [Service]
> User=debian-transmission
> Type=notify
> ExecStart=/usr/bin/transmission-daemon -f --log-error
> ExecStop=/bin/kill -s STOP $MAINPID
> ExecReload=/bin/kill -s HUP $MAINPID
> 
> [Install]
> WantedBy=multi-user.target
> 
> 


t-d.strace
Description: Binary data


stats
Description: Binary data

Re: transmission-daemon и постоянные обращения к диску

2017-03-28 Пенетрантность dimas 
2017-087 22:48 Igor Savlook  wrote:
> Тоесть он лог постоянно пишет на диск не прекращая? После того как ты
> лог направил в /dev/null все ок?
именно так!
причем я хз, что он туда пишет, в лог-файле ничего нового не появляется, но в
iotop при этом постоянная запись от процесса t-d.
с lsof я не особо разобрался, у него какой-то наркоманский синтаксис, плюс он
еще сетевые все запросы до кучи сыплет, и -X не помогает.
но факт в том, что после -e /dev/null все успокоилось, да

Re: transmission-daemon и постоянные обращения к диску

2017-03-28 Пенетрантность Tim Sattarov 
On 28/03/17 03:08 PM, dimas wrote:
> поставил iotop, и сабж стал постоянно светиться в столбце "write". подумал,
> куда он там может пытаться писать - первое подозрение: что-то в логи тоннами
> шлет. в syslog он не пишет, вроде как, а собственный его лог-файл я посмотрел 
> -
> там несколько строчек всего, и ничего нового не появляется. в опциях стояло
> --log-error, именно так все и работало (несколько записей про одну раздачу,
> которая не найдена на таком-то трекере)
> однако же, после того как в /etc/default/сабж я задал -e /dev/null и
> перезапустил - он перестал насиловать мой несчастный диск. а при заданном
> лог-файле не только диод моргал, но и, если ухо приложить, слышно было, как
> бедный диск заводится каждый раз.
я бы проверил ещё strace'ом, что он пишет и куда
strace  -e write -p `pidof transmission-daemon`
и вот сюда ещё:
journalctl  -u transmission-daemon.service

у меня transmission-daemon из тестинга:

# apt-cache  policy transmission-daemon
transmission-daemon:
  Installed: 2.92-2
  Candidate: 2.92-2
  Version table:
 *** 2.92-2 500
500 https://cloudfront.debian.net/debian unstable/main amd64
Packages
400 https://cloudfront.debian.net/debian testing/main amd64 Packages
100 /var/lib/dpkg/status


весь запуск и опции управляются через systemd:

[Unit]
Description=Transmission BitTorrent Daemon
After=network.target

[Service]
User=debian-transmission
Type=notify
ExecStart=/usr/bin/transmission-daemon -f --log-error
ExecStop=/bin/kill -s STOP $MAINPID
ExecReload=/bin/kill -s HUP $MAINPID

[Install]
WantedBy=multi-user.target

Re: transmission-daemon и постоянные обращения к диску

2017-03-28 Пенетрантность Igor Savlook 
On Tue, 2017-03-28 at 22:08 +0300, dimas wrote:
> алярм всем, кто пользует transmission-daemon, по крайней мере
> актуальную версию
> из тестинга!
> сегодня заметил, что на сервере постоянно мигает диод доступа к
> диску, где-то
> раз в секунду. опытным путем быстро выяснилось, что после остановки
> сабжа
> перестает мигать, с запуском - начинает. фишка в том, что диод
> отвечает за
> системный диск, на котором кроме самой системы ничего нет, вся
> файлопомойка (и
> раздачи) - на внешних дисках.
> поставил iotop, и сабж стал постоянно светиться в столбце "write".
> подумал,
> куда он там может пытаться писать - первое подозрение: что-то в логи
> тоннами
> шлет. в syslog он не пишет, вроде как, а собственный его лог-файл я
> посмотрел -
> там несколько строчек всего, и ничего нового не появляется. в опциях
> стояло
> --log-error, именно так все и работало (несколько записей про одну
> раздачу,
> которая не найдена на таком-то трекере)
> однако же, после того как в /etc/default/сабж я задал -e /dev/null и
> перезапустил - он перестал насиловать мой несчастный диск. а при
> заданном
> лог-файле не только диод моргал, но и, если ухо приложить, слышно
> было, как
> бедный диск заводится каждый раз.
> баг сейчас накатаю, если еще нету, а пока что все обратите внимание,
> если вам
> дороги ваши винты
> 

Тоесть он лог постоянно пишет на диск не прекращая? После того как ты
лог направил в /dev/null все ок?

transmission-daemon и постоянные обращения к диску

2017-03-28 Пенетрантность dimas 
алярм всем, кто пользует transmission-daemon, по крайней мере актуальную версию
из тестинга!
сегодня заметил, что на сервере постоянно мигает диод доступа к диску, где-то
раз в секунду. опытным путем быстро выяснилось, что после остановки сабжа
перестает мигать, с запуском - начинает. фишка в том, что диод отвечает за
системный диск, на котором кроме самой системы ничего нет, вся файлопомойка (и
раздачи) - на внешних дисках.
поставил iotop, и сабж стал постоянно светиться в столбце "write". подумал,
куда он там может пытаться писать - первое подозрение: что-то в логи тоннами
шлет. в syslog он не пишет, вроде как, а собственный его лог-файл я посмотрел -
там несколько строчек всего, и ничего нового не появляется. в опциях стояло
--log-error, именно так все и работало (несколько записей про одну раздачу,
которая не найдена на таком-то трекере)
однако же, после того как в /etc/default/сабж я задал -e /dev/null и
перезапустил - он перестал насиловать мой несчастный диск. а при заданном
лог-файле не только диод моргал, но и, если ухо приложить, слышно было, как
бедный диск заводится каждый раз.
баг сейчас накатаю, если еще нету, а пока что все обратите внимание, если вам
дороги ваши винты