LINUX.ORG.RU
ФорумTalks

VLC засрал системный лог

 , ,


0

1

Смотрел вчера пиратские видеокурсы, надоело, отправил компьютер в ждущий режим и успал. Утром после включения выскочило сообщение о нехватке свободного места; перебрав все файлы, я обнаружил, что syslog опух и продолжает пополняться ошибками вида

/usr/libexec/gdm-x-session[1182743]: [00007f9b440a64d0] vdpau_chroma filter error: video mixer features failure: An invalid handle value was provided.
со скоростью порядка 16 мегабайт в секунду. После закрытия VLC проблема устранилась.

Продолжаю наблюдения.

После закрытия VLC проблема устранилась.

вот когда убьют тогда и приходите

Shulman
()
Ответ на: комментарий от fornlr

Кста, насчёт вендорлоков и необходимости зелени. Там красные анонсировали убийцу™ CUDA, некоторый GPUFORT. Не в курсе, шо оно такое и зачем, когда есть OpenCL?

izzholtik ★★★
() автор топика
Ответ на: комментарий от karton1

А что не так собсна?

В том что не всегда ждущий режим - это ждущий режим.

Кошерный ждущий режим - это когда у тебя на АТХовом блоке питания выключается модуль 5в-12в и работает только дежурка.

Но сейчас под «ждущим режимом» подразумевается отключение дисплея и перевод проца в нижнюю частоту. Правда это может быть вина не Линукса а просто кривой реализации.

windows10 ★★★★★
()
Ответ на: комментарий от windows10

Кошерный ждущий режим - это когда у тебя на АТХовом блоке питания выключается модуль 5в-12в и работает только дежурка.

лет 20 назад, это называлось спящим режимом. со сбросом памяти на диск.

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

n_play
()
Ответ на: комментарий от n_play

лет 20 назад, это называлось спящим режимом. со сбросом памяти на диск.

Нэд. Гибернация - это другое. При гибернации ты можешь даже физически обесточить комп.

В ждущем режиме, должна работать только дежурка для рефреша ОЗУ и контроллинга прерываний (нет, не тех) от устройств которым позволено пробуждать комп ото сна.

windows10 ★★★★★
()
Ответ на: комментарий от windows10

ты тоже чтоли идиот?

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

дежурку нельзя нагружать ничем. она не для этого.

В ждущем режиме, должна работать только дежурка для рефреша ОЗУ и контроллинга прерываний (нет, не тех) от устройств которым позволено пробуждать комп ото сна.

для рефреша ram нужен работающий контролер памяти. а дальше давай по цепочке умозаключений выведи что должно еще работать. и самое главное как это это связано со stand-by режимом ожидания включения подачи питания.

либо, что крайне вероятнее, у тебя какое-то особое свое толкование термина дежурное питание.

n_play
()
Ответ на: ты тоже чтоли идиот? от n_play

Тут не ноутбук, где можно и нужно по-людски питаловом рулить, тут восратый ATX с одним PowerGood'ом. То есть, ну, вариантов не так много - либо он прижат к земле, и БП воет вентиляторами, либо отпущен, и вся та шняга, что подключена к системнику - мыши, клавиатуры, PCIная сетевушка, заряжающийся китайфон, а также рама, ейный контроллер в процессоре и всякая хабово-мостовая муть, обеспечивающая просыпание по эни кей на USB и PS/2 - жрут что дадено. Дежурное питание то есть.

izzholtik ★★★
() автор топика
Последнее исправление: izzholtik (всего исправлений: 2)
Ответ на: ты тоже чтоли идиот? от n_play

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

Ага. От внешних сигналов. Кнопки включения. Двигания мышкой. Пульта в случае если компьютер у тебя в телевизоре. Или почему ты думаешь при ждущем режиме в USB присутствует пять вольт ?)

дежурку нельзя нагружать ничем. она не для этого.

Врешь. В некоторых биосах ты можешь выставлять возможность зарядки через USB в дежурном режиме. Например у меня такое есть.

для рефреша ram нужен работающий контролер памяти. а дальше давай по цепочке умозаключений выведи что должно еще работать.

Для работающего контроллера памяти нужен работающий контроллер памяти. Реализация рефреша зависит от конкретного контроллера. Например в ARM этот блок достаточно подпитывать полусекундными импульсами раз в 15 сек.

windows10 ★★★★★
()
Ответ на: комментарий от izzholtik

ого, это какая драм 15 секунд заряд держит?

15 сек для контроллера это ж не 15 сек для драм. Может там кондеры стоят, или еще хз как. Реверс-инжинирну глубже, и дам знать :)

windows10 ★★★★★
()
Ответ на: комментарий от karton1

Дак если не ноутбук, то какая разница?

В большинстве случаев - никакой.

В меньшинстве случаев - лишнее тепловыделение и энергопотребление.

В пределах одного компьютера - незаметно. А если рабочих мест две сотни, то разница может быть около сотни намотанных киловатт за выходные, пока персонал «отправил ПК в ждущий режим» и отдыхает дома.

windows10 ★★★★★
()

а если у тебя еще и journald, то он и половину процессора на этом съедает. ляпота! как ты очистил лог в итоге?

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 1)

Не используй Vdpau для вывода видео. Там сейчас нвидия забила болт на него и продвигает nvdec. Там емнип сейчас намного лучше работает другая опция (сейчас не на линуксе точно не помню) вроде как подварианты вывода opengl.

bhfq ★★★★★
()
Ответ на: комментарий от izzholtik

intelfx, заходи, не стесняйся. как ты там писал в нашем споре про очистку лога? я придумал какой-то дебильный кейс, которого никогда не бывает и который ничего не доказывает, да?) предлагал тебе решить «неправильную» задачу, да?) вот тот самый пример, когда с systemd стало хуже. юзерские ошибки, которые должны были пойти в отдельный лог, смешались с системными. в итоге потеряно все.

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 2)
Ответ на: комментарий от izzholtik

Когда я последний раз пользовался vdpau правда под не стабильной опенсусе (не уверен что дело в этом) там vdpau жрало 30% CPU и 30% GPU, когда opengl -> vaapi вывод кушал 0% и 10%.

bhfq ★★★★★
()
Ответ на: комментарий от crypt

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

izzholtik ★★★
() автор топика
Ответ на: комментарий от crypt

просто добавлю его в список дебильного софта, который глючит после ждущего режима и подлежит убийству в конце дня. ЧСХ, весь список использует GPU..)

izzholtik ★★★
() автор топика
Ответ на: комментарий от izzholtik

а, так этот глюк только после пробуждения? ну тогда видеокарта, действительно, неправильно инициализируется после саспенда. а дистр какой?

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 1)
Ответ на: комментарий от crypt

Убунта.

Это широко распространённый в узких кругах блобобаг. Иногда он начинает срать после смены пользователя при воспроизведении видео от предыдущего, иногда вообще непонятно почему. Я потому такие теги и поставил.

izzholtik ★★★
() автор топика
Ответ на: комментарий от crypt

Ты не только придумал дебильный кейс, ты ещё и вспомнил его максимально не к месту, а тупо потому что у тебя триггер сработал на слова «логи» и «systemd».

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

о, ты фанатично отрицаешь проблему в треде, который ее наглядно иллюстрирует) конечно, мы с izzhotlink неправильные:) один ты д'артаньян)))

crypt ★★★★★
()
Ответ на: комментарий от izzholtik

мы с ним технические парни. напиши, пожалуйста, максимально точно.

crypt ★★★★★
()
Ответ на: комментарий от crypt

Ты способен заметить разницу между высказываниями «запущен процесс journald» и «логи пишутся на диск в нативном формате journald»?

Journald в данном случае выполняет роль микропрослойки, которая собирает stderr от процессов, аннотирует его и пересылает дальше.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

я конкретно спросил ТСа: VLC засрал системный лог (комментарий)

не моя вина, что он не уточнил, что у него journald в режиме прокси.:( на мой взгляд запускать одну систему логирования через другую - это не юниксвей и дебильно (т.к. ни одна программа не выполняет свою функцию хорошо). но если у вас это норма... у вас, значит, дважды жрали ресурсы: и journald (почему он тогда в iotop, если не пишет на диск?), и обычный сислог. зашибись.

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 2)

Была та ж проблема. VLC пробуждается некорректно. И не только в логи начинает срать (тыц, у меня срало в ~/.xsession-errors), но и чёрное окно вместо видео (вроде до сих пор, несколько лет уже). Забивающий весь диск ~/.xsession-errors вылечил, пропатчив lightdm – вообще запретил в него писать.

dimgel ★★★★★
()
Ответ на: комментарий от crypt

не моя вина

Да-да, это не ты, это тебе в штаны <…>. Обосрался — хотя бы признай.

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

на мой взгляд запускать одну систему логирования через другую - это не юниксвей и дебильно (т.к. ни одна программа не выполняет свою функцию хорошо). но если у вас это норма

На мой взгляд, тебя надо из профессии ссаными тряпками гнать за тугодумие.

Когда с одной стороны программа пишет в stderr в свободной форме, а с другой стороны syslog-демон принимает сообщения согласно конкретному протоколу, между ними обязан быть процесс-посредник, который будет читать один поток и формировать другой.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от intelfx

я признаю, что обосрался не раньше, чем ты ответишь по существу моего поста:

у вас, значит, дважды жрали ресурсы: и journald (почему он тогда в iotop, если не пишет на диск?), и обычный сислог. зашибись.

crypt ★★★★★
()
Ответ на: комментарий от crypt

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Когда с одной стороны программа пишет в stderr в свободной форме, а с другой стороны syslog-демон принимает сообщения согласно конкретному протоколу, между ними обязан быть процесс-посредник

минутку! кто на ком стоял? при чем здесь вообще syslog? от граф.режима сообщения всегда и принимались в свободном формате и писались в $HOME/.xsession-errors (вариант в /dev/null, если мы не хотели их читать). теперь ты мы имеет systemd, который by design хочет владеть всеми логами, но поскольку ТС почему-то не хочет хранить их в нативном формате journald, а сам journald не умеет syslog формат, то у нас получается эта цепочка

stderr -> gdm-x-session -> journald -> syslog -> /var/log/syslog

и это при потоке 16мб/сек. офигеть!

crypt ★★★★★
()
Ответ на: комментарий от intelfx

Это уже совершенно отдельный вопрос

ах да! это другое! ну извини, я тогда не готов признать, что обосрался.

crypt ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.