Как командой перезагрузить компьютер с KDE?

/sbin/reboot

http://askubuntu.com/questions/1871/how-can-i-safely-shutdown-reboot-logout-k...

sudo reboot

emu-nero~: правильный ответ REISUB

\\паста из чатика\\

Такое ощущение, будто один staseg читал сообщение при треде.

Неужели KDE настолько криво сделано, что не может завершиться по SIGTERM?

Мне не нужно завершение по SIGTERM, чтобы потом некоторые приложения жаловались, что я их жестоко убил.

Прочитав ссылку и вообще инструкцию, пришел к выводу, что надо сделать так:

qdbus org.kde.ksmserver /KSMServer org.kde.KSMServerInterface.logout -0 -1 -2

Удваиваю вопрос. Всегда считал, что reboot/shutdown вполне корректный способ перезагрузки/завершения работы вне зависимости от DE.

Да блджад, неужели нельзя не обсуждать, нужно ли мне это, а ответить по сути?

Мне не нужно завершение по SIGTERM, чтобы потом некоторые приложения жаловались, что я их жестоко убил.

Это кривые приложения, ведь SIGTERM это не SIGKILL. SIGTERM — вежливое требование прекратить выполнение, если же приложение не в состоянии его корректно выполнить, то оно кривое. Самый известный пример, к сожалению, это Firefox.

Я как раз по необходимости пользуюсь и Chrome и Firefox. Именно поэтому мне нужно грамотное завершение.

У меня они не ругаются, после отправки SIGTERM, проверь у себя.

Тоже. Стоп. Тогда что происходит во время reboot?

Последовательно отправляются сигтермы приложениям, ЕМНИП. Попробуй sudo init 6 выполнить, а потом проверь.

man SysRq

Блджад...

Работа была завершена некорректно...

Костыль:

Напиши скриптик, который будет отправлять SIGTERM активным приложениям (или только проблемным) и будет выполняться перед reboot.

Я как-то раньше делал это, точную комбинацию флагов не помню - там по ссылке они расписаны. Или ты напутал с флагами, либо запустил кеды не через KDM, тогда им вполне может просто не хватить прав на ребут.

Нашел на одном сайте другой вариант.

dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Restart

AFAIK проблема ещё в том, что не все успевают завершиться до прихода sigkill от init. DE же обычно терпеливо ждёт, пока завершатся все процессы.

[НЕНАВИСТ] firefox не обрабатывает нормально SIGTERM (комментарий)

если же приложение не в состоянии его корректно выполнить, то оно кривое. Самый известный пример, к сожалению, это Firefox.

А чё Firefox, оно вполне себе по умному делает. Если оно прекратило свою работу не обычным образом, то оно при следующем запуске восстанавливает предыдущую сессию.

kdeinit4_shutdown --help
Usage: kdeinit4_shutdown

Shuts down kdeinit4 master process and terminates all processes spawned from it.

Ну а после него можно и reboot. Я, правда, не парюсь, а ребучу прямо из кед командой reboot, никаких проблем. Только Akregator спрашивает, восстановить ли предыдущую сессию (не знаю что это значит, я соглашаюсь).

Может подойдет вариант... сначало завершить сеанс с сохранением а потом reboot.

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

кстати да, сам хотел dbus посоветовать. он же для подобного и создан.

shutdown -r now еще

Это кривые приложения, ведь SIGTERM это не SIGKILL. SIGTERM — вежливое требование прекратить выполнение, если же приложение не в состоянии его корректно выполнить, то оно кривое. Самый известный пример, к сожалению, это Firefox.

когда я пытался вот таким образом обработать sigterm в deadbeef, столкнулся с нерешаемой проблемой, и заключается она вот в чем.

когда юзер запускает reboot/shutdown — всем процессам посылается sigterm. в т.ч. wm, иксам, и черт знает чему еще. главное — иксы от этого завершаются.

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

думаю, для решения этой проблемы и придумали session manager, libeggsmclient, и т.п.

странно, что для решения этой проблемы в gtk не сделали возможность просто не прибивать процесс при потере коннекта.

странно, что для решения этой проблемы в gtk не сделали возможность просто не прибивать процесс при потере коннекта.

угу, странно. может и сделали, но я не нашел.