Что ни клиент, то либо сегфолтится по настроению, либо по функциям не дотягивает даже до pygmy. Убожество как оно есть. Добавим сюда тормозную базу в совершенно непригодном для фонотеки формате :-/
базу не использую (кстати, а чем sqlite хуже, чем свой велосипед?) - у меня «хорошо лежат», родной консольный клиент работает без нареканий (с автодополнением в zsh всё вообще ок), с гуями, да, проблематично, я всё думал взяться за lxmusic (как самый непадучий и больше всего похожий на мои представления о юзабельном аудиоплеере) и довести до ума, но пока руки не доходят (как обычно, ага).
Но сам плеер, как по мне, в сумме заруливает mpd (для десктопа, не для сервера).
Собственно, я mpd выбросил, когда увидел, что мне нужно за каким-то фигом запускать демон отдельно (клиенты этого не делают), плюс тогда он не умел играть файлы без добавления базы. Может сейчас ситуация поменялась, но впечатление было испорчено. А xmms2 сразу заработал как хотелось, что называется, искаропки.
Отказался от mpd + gmpc в пользу Clementine. Доволен, плеер очень удобный. Хорошо работает с тегами из коробки, удобно просматривать коллекцию. В отличие от exaile - не тормозит.
у меня костыльная джампилка по хистори на sqlite3 | dmenu работает практически моментально даже на атомном нетбуке, так что тормозит фокс вовсе не из-за базы :)
Вот этот да, кривоват, но на фоне прочих хоть как-то напоминает конечный продукт.
угу, такое впечатление, что аффтар задался целью нарушить все существующие HIG-и
необходимость этот демон явно останавливать при logout.
Нет, просто масштаб не тот. Десяток тысяч записей с десятком полей не проблема, а вот попробуйте в FF сделать выборку в истории на 100-200 тысяч записей и нажать Del — слайдшоу на несколько минут с периодическими вопросами лисы «точно продолжить выполнение скрипта? (о.О)» гарантировано. Хотя да, JS тут тоже способствует.
а зачем?
Не даёт сделать вручную umount /home. При этом не отражается в зеркалахlsof и fuser.
как не тот? я делаю выборку именно из фоксовской (ну, точнее, conkeror-овской, хотя xul и база те же) истории. Так что основные тормоза именно из-за js-а.
Почему вы сомневаетесь в надёжности Xreset и logout-скриптов шеллов?
Ненадёжны они, потому что не выполнятся. Например, если xinit или DM (или что там будет запускать этот Xreset) будут убиты SIGKILL (например, OOM-killer'ом; возможно, даже SIGKILL не обязателен, а хватит SIGTERM или SIGHUP — например, остановка DM администратором), то эти скрипты точно не выполнятся. И да, не понимаю, при чём тут logout-скрипт шелла.
Далее, с точки зрения практической пригодности этого способа: что вы напишете в эти скрипты? killall mpd? И какое это отношение будет иметь к сессии пользователя? Юзер мог залогиниться 2 раза и запустить 2 mpd из-под разных сессий, а убиты должны быть только те mpd, которые запущены в завершающейся сессии. Поэтому это не решение, а в скрипте придётся среди всех mpd выбирать те, которые относятся к нужной сессии, и убивать их. А для этого нужен systemd-logind или ConsoleKit (насчёт последнего не уверен, что он такое умеет). Но т.к. для этого всё равно нужен systemd-logind, а он и сам умеет убивать нужные процессы при завершении сессии, то необходимость в скрипте плавно отпадает.
То, что я сказал, можно отнести к любому процессу, а не только к mpd.
Ненадёжны они, потому что не выполнятся. Например, если xinit или DM (или что там будет запускать этот Xreset) будут убиты SIGKILL (например, OOM-killer'ом; возможно, даже SIGKILL не обязателен, а хватит SIGTERM или SIGHUP — например, остановка DM администратором), то эти скрипты точно не выполнятся
Да.
И да, не понимаю, при чём тут logout-скрипт шелла.
При том, что не все пользуются DM.
Далее, с точки зрения практической пригодности этого способа: что вы напишете в эти скрипты? killall mpd?
Ну, если вы хотите рассмотреть именно MPD, то я туда напишу mpd --kill, который сверяется с pid-файлом :)
И какое это отношение будет иметь к сессии пользователя? Юзер мог залогиниться 2 раза и запустить 2 mpd из-под разных сессий, а убиты должны быть только те mpd, которые запущены в завершающейся сессии.
Если он их запустил корректно, с разными сокетами/портами и pid-файлами, то, очевидно, всё будет хорошо. Если некорректно, то убивать надо все копии, потому что это не является нормальным режимом работы MPD. У меня он запускался с проверкой на предмет наличия уже запущенных экземпляров.
А для этого нужен systemd-logind
А каким образом оно определяет принадлежность к конкретной сессии процессов, не имеющих управляющего терминала?
То, что я сказал, можно отнести к любому процессу, а не только к mpd.
Де-факто, о нескольких демонах позаботиться несложно. Остальные же являются X-клиентами и/или дочерними процессами логин-шелла, поэтому разуплотнятся автоматически при любом сценарии завершения сессии. А если не разуплотнятся, то это наверняка уже зомби, с которыми возиться бессмысленно.
А каким образом оно определяет принадлежность к конкретной сессии процессов, не имеющих управляющего терминала?
Оно использует только cgroups для определения принадлежности процессов к сессиям. Наглядно увидеть это можно, например, в /sys/fs/cgroup/systemd/user/$USER/$SESSION/tasks.
Ну, если вы хотите рассмотреть именно MPD, то я туда напишу mpd --kill, который сверяется с pid-файлом :)
PID-файлы ненадёжны. Если даже не говорить о том, что приложение никак не может его предохранить от перезаписи и удаления, то всё равно остаются проблемы. Если PID-файл лежит в /tmp, то он может пропасть в любой момент, потому что /tmp может быть очищено когда угодно. В /run обычные пользователи писать не могут (/run/user/* появилось не так давно, и ещё почти ничем не используется). Если он лежит в другом месте, то там может остаться содержимое с прошлой загрузки, поэтому может быть убит произвольный процесс.
Де-факто, о нескольких демонах позаботиться несложно.
Вот именно, нужно для каждого демона писать разные костыли. Если добавляется ещё один демон, то каждому пользователю нужно будет дописать скрипт, чтобы он убивал и новый демон тоже. А с systemd-logind всё проще: нужно один раз настроить PAM и забыть, потом всё просто работает.
У меня они лежали в домашнем каталоге, никаких проблем.
gentoo_root
Если он лежит в другом месте, то там может остаться содержимое с прошлой загрузки, поэтому может быть убит произвольный процесс.
Например, такой сценарий: аварийное завершение, pid-файл не удалился, при следующей загрузке mpd не стартует (например, он обновлялся во время аварийного завершения), остаётся старый pid-файл от предыдущей загрузки, при mpd --kill убивается левый процесс.