С GNU или FreeBSD find
, можно использовать -quit
предикат:
find . ... -print -quit
NetBSD find
эквивалентный:
find . ... -print -exit
Если все, что Вы делаете, печатает имя и предполагает, что имена файлов не содержат символы новой строки, Вы могли сделать:
find . ... -print | head -n 1
Это не остановится find
после первого соответствия, но возможно, в зависимости от синхронизации и буферизации на второе соответствие или (намного) позже. В основном, find
будет завершен с SIGPIPE, когда он попытается произвести что-то в то время как head
уже не стал, потому что это уже считало и отобразило первую строку входа.
Обратите внимание, что не все оболочки будут ожидать этого find
команда после head
возвратился. Реализации Оболочки Bourne и AT&T ksh
(когда неинтерактивная) и yash
(только если тот конвейер является последней командой в сценарии), не был бы, оставляя его работающий в фоне. Если Вы видели бы, что поведение в любой оболочке, могли всегда изменять вышеупомянутое на:
(find . ... -print &) | head -n 1
При выполнении больше, чем печать путей найденных файлов Вы могли бы попробовать этот подход:
find . ... -exec sh -c 'printf "%s\n" "$1"; kill "$PPID"' sh {} \;
(замена printf
с чем Вы сделали бы с тем файлом).
Это имеет побочный эффект find
возврат статуса выхода, отражающего то, что это было уничтожено все же.
На самом деле, с помощью сигнала SIGPIPE вместо SIGTERM (kill -s PIPE
вместо kill
) заставит некоторые оболочки быть более тихими о той смерти (но все еще возвратил бы ненулевой статус выхода).
Попытайтесь завершить работу сервиса, прежде чем приостановят и запустятся снова после резюме. Как этот:
http://oleeekchoff.blogspot.ie/2012/05/restart-modulesservices-after.html
Я не знаю, стандартно ли это, но в Ubuntu существует сценарий, которые выполняются, прежде приостанавливают / после резюме в /etc/pm/sleep.d
и в /usr/lib/pm-utils/sleep.d
. В моей системе кажется, что сеть закрывается /usr/lib/pm-utils/sleep.d/60_wpa_supplicant
.
Можно записать сценарий, например, /etc/pm/sleep.d/10-umount
для размонтирования долей прежде приостанавливают. Структура этих сценариев похожа на это:
#!/bin/sh
#
case "${1}" in
suspend|hibernate)
# your command to umount here
;;
resume|thaw)
# (possibly) your command to mount here
;;
esac
Заметьте, что, если сценарий возвращает универсальную ошибку, приостанавливание прерывается, поэтому заботиться об этом (особенно Вы, как я, используйте, чтобы закрыть крышку и хранить ноутбук...). Написать сценарий более сложных вещей, благодаря Samuel Peter для его комментария:
можно возвратить ошибку, не прерывая приостанавливание путем возвращения одного из специальных значений, определенных в
/usr/lib/pm-utils/pm-functions
:$NA
"не применимо",$DX
"отключен", и$NX
"не исполняемый файл". Посмотритеhook_exit_status
функция в сценарии пополудни-функций
Вы могли даже повторно смонтировать их после резюме автоматически; отсюда я нашел что:
Если Вы хотите сделать, что-то характерное для Вашей установки во время приостанавливает или в спящем режиме, то можно легко поместить собственный рычаг в/etc/pm/sleep.d. Рычаги в этом каталоге назовут в алфавитном порядке во время, приостанавливают (который является причиной их имена, все начинают с 2 цифр, делать упорядочивание явным), и в обратном порядке во время резюме.
Так включая тот же сценарий umount
и mount command
должен работать (в, приостанавливают его, выполняется прежде, чем закрыть сеть, и в резюме после этого).
Ссылка в Вашем вопросе является разоблачающей; именно моя интерпретация, если NetworkManager закрывает сеть перед сценариями на уровне 00-50, выполняется, это - ошибка---, по крайней мере, если соединение отмечено как системное соединение (в Параметрах сети-> Опции->, Идентификационные данные-> Делают доступными для другого пользователя).
pm-utils
должно быть доступным на всех основных дистрибутивах и вероятно установлен по умолчанию.
– goldilocks
26.11.2013, 19:44
$NA
"не применимо", $DX
"отключен", и $NX
"не исполняемый файл". Посмотрите hook_exit_status
функция в сценарии
– Samuel Peter
26.11.2013, 20:46
system connection
свойство.Править: Это уже был a system connection
.
– C-Otto
01.12.2013, 14:10
Вы могли попытаться узнать почему nm
закрывает устройства:
dbus-monitor --system &
nmcli g logging level DEBUG
--> trigger suspend
Когда (как в моем случае (Fedora 20)), systemd
инициировал сигнал, можно отклонить его доставку в dbus конфигурации:
---- /etc/dbus-1/system.d/99-my-suspend.conf ---
<busconfig>
<policy user="root">
<deny receive_interface="org.freedesktop.login1.Manager"
receive_type="signal"
receive_member="PrepareForSleep"/>
</policy>
</busconfig>
К сожалению, эти правила не являются очень мелкомодульными, и это заблокируется PrepareForSleep
сигнал для других процессов также.
Основываясь на том, что сказал @ensc, вы можете вместо этого прослушать сигнал D-Bus (системной сессии) самостоятельно. Общий процесс работы с интерфейсом org.freedesktop.login1.Manager
был бы:
Inhibit(what, who, why, mode)
what
: sleep
or shutdown:sleep
who
: unmount_cifs
или как вы там называете ваш скрипт почему
: размонтирование cifs X до приостановки ...
или эквивалентныйрежим
: задержка
для блокировки на макс. 5 с (по умолчанию) или блок
для блокировки на неопределенное время (я бы рекомендовал первое. Если ваш скрипт задерживается, ноутбук просто никогда не засыпает.)PrepareForSleep
, который возвращает True
, когда собирается приостановить или впасть в спячку, и False
, когда возобновляется и оттаивает)PrepareForShutdown
, который возвращает True
при выключении и должен возвращать False
при включении (вместо этого он также возвращает False
в то же время он возвращает True
, что для меня не имеет никакого смысла, поэтому я бы просто проигнорировал здесь часть False
; у вас, наверное, уже есть какой-нибудь скрипт для автоматического запуска системы, не так ли? )True
(т.е. размонтирование), вы освобождаете блокировку, закрывая дескриптор файла (возвращается функцией Inhibit(..... )
), чтобы машина как можно быстрее перешла в спящий режим или выключилась, не дожидаясь целых 5 секунд (или даже бесконечно, когда в режиме block
)False
(возобновить/оттопить), перемонтировав (может быть, сначала дождавшись включения сети), а затем создав новый замок с помощью Inhibit(.... )
(для следующего сна или выключения)На Python (2.7) это может выглядеть так:
#!/usr/bin/env python
import os, atexit, dbus, gobject
from dbus.mainloop import glib
def login1ManagerDBusIface():
system_bus = dbus.SystemBus()
proxy = system_bus.get_object( 'org.freedesktop.login1',
'/org/freedesktop/login1' )
login1 = dbus.Interface( proxy, 'org.freedesktop.login1.Manager')
return login1
def sleepShutdownInhibit():
login1 = login1ManagerDBusIface()
fd = login1.Inhibit( 'shutdown:sleep', 'unmount_cifs',
'Unmounting before suspend/shutdown ...',
'delay' )
return fd
def take_lock():
global FD
FD = sleepShutdownInhibit()
def remove_lock():
global FD
if FD:
os.close( FD.take() )
FD = None
def signal_handler(boolean, member=None):
if boolean: ## going to suspend/hibernate or shutdown
## PLACE YOUR UNMOUNT STUFF HERE
remove_lock()
else: ## resume/thaw
if member == 'PrepareForSleep':
## PLACE YOUR MOUNT STUFF HERE
take_lock()
if __name__ == '__main__':
take_lock()
atexit.register(remove_lock)
login1 = login1ManagerDBusIface()
for signal in ['PrepareForSleep', 'PrepareForShutdown']:
login1.connect_to_signal(signal, signal_handler,
member_keyword='member')
glib.DBusGMainLoop(set_as_default=True)
loop = gobject.MainLoop()
loop.run()
В этой Gist вы найдете мою обертку вокруг Pidgin для отключения IM аккаунтов во время сна и выключения, используя точно такой же подход.
Смотрите также официальную документацию по фридектопу на Inhibitor Locks и logind
D-Bus API.