Как обмануть приложение для выполнения различных процессов?
Спасибо Омни. Даже следующим образом, я могу достичь этого. Конечно, Урс - это просто. Спасибо большое
grep -H "exit 0" /opt/ctmagent/ctm/sysout_archives/141027/d_dms_btch_alrt_ifm_scp_ksh* | awk -F":" '{system("ls -latr "$1"")}'
-121--133827-
Из ваших других вопросов я понимаю, что вы используете OS X. Файловая система HFS + по умолчанию в OS X не учитывает регистр: вы не можете иметь два файла с именами «abc» и «ABC» в одном каталоге, и при попытке доступа к любому имени вы получите одно и то же имя То же самое может произойти при Cygwin или с файловыми системами без учета регистра (например, FAT32 или ciopfs ) в любом месте.
Поскольку grep является реальным исполняемым файлом, он находится в файловой системе (в каталогах PATH ). При поиске в оболочке /usr/bin для grep или GREP будет найден исполняемый файл grep .
Сборки оболочки не просматриваются в файловой системе: поскольку они встроены, доступ к ним осуществляется посредством (с учетом регистра) строковых сравнений внутри самой оболочки.
То, с чем вы сталкиваетесь - интересный случай. В то время как cd является builtin, доступ к нему осуществляется с учетом регистра, CD находится в виде исполняемого файла /usr/bin/cd . Исполняемый файл cd довольно бесполезен: поскольку cd влияет на текущую среду выполнения оболочки, он всегда предоставляется как обычная встроенная оболочка , но существует cd исполняемая для POSIX sake , которая в любом случае изменяет каталог для себя, а затем немедленно прекращает работу, оставляя окружающую оболочку там, где она начиналась.
Вы можете попробовать их с помощью type builtin :
$ type cd
cd is a shell builtin
$ type CD
CD is /usr/bin/CD
type указывает, что будет делать оболочка при выполнении этой команды. При запуске cd вы получаете доступ к builtin, но CD находит исполняемый файл. Для других построений builtin и исполняемый файл будут разумно совместимы (попробуйте echo ), но для cd это невозможно.
-121--13497-
Удалить пустую строку перед выкладкой -командой. Команда post-up должна быть связана только с eth0 .
Дополнительно переместите сценарий из папки if-up.d . Сценарии в этой папке выполняются автоматически, независимо от того, определены ли они как post-up . В вашем случае он будет выполняться дополнительно к вашей команде post-up .
Процесс, который не удалось выполнить, является причиной того, что либо системе не хватает памяти, либо пользователь поразил их максимальное количество процессов - например, из-за вилочной бомбы.
Мне любопытно, как вы знаете, что/tmp заполнен, если вы не можете войти в машину - но я предполагаю, что любой процесс заполнен/tmp также может высасывать ресурсы, необходимые для вас, чтобы ssh в.
Если у вас есть физический доступ к машине, вы можете попытаться с помощью входа в консоль вернуть вещи в пригодное для использования состояние или использовать магический sysreq (предполагая, что это машина Linux), чтобы получить контроль над вещами.
Вы также можете получить sftp работать, даже когда ssh не будет, так как он должен использовать меньше памяти и вилки меньше раз, чем оболочка - и вы можете использовать его для удаления файлов с удаленного, если вы можете войти в систему.
-121--129061-Процесс является экземпляром программы. Программа может быть создана несколько раз, то есть несколько процессов могут быть созданы с одним и тем же загруженным исполняемым кодом. Я хотел бы процитировать строку из Понимание ядра Linux Даниэля П. Бовета и Марко Чезати:
Важно отличать программы от процессов; несколько процессов могут выполнять одну и ту же программу одновременно , в то время как один и тот же процесс может выполнять несколько программ последовательно .
В основном это означает, что, хотя программа может быть запущена в нескольких экземплярах, один экземпляр может одновременно загружать только один исполняемый код. Так что, начав оттуда, можно было бы сказать, что ничто не мешает программе нарваться на несколько экземпляров, потому что нет абсолютно никаких оснований ее запрещать. Конечно, эти процессы не будут делиться ничем, кроме кода исполнения. Страницы памяти, дескрипторы файлов (которые могут касаться идентичных файлов) и так далее... полностью независимы от одного процесса к другому.
Еще один пункт, который мне кажется важным, когда речь идет о Unix-подобных системах (та же книга):
Unix-подобные операционные системы принимают модель процесса/ядра . Каждый процесс имеет иллюзию того, что это единственный процесс на компьютере , и имеет эксклюзивный доступ к службам операционной системы.
Действительно, именно поэтому системы Unix являются многопроцессорными/мультипрограммными или, по крайней мере, это политика, на которой основана эта функция. Таким образом, из-за этого самого факта нет пути для процесса знать , что другой процесс, выполняющий точно такой же код, ожидает или работает на другом CPU.
Однако каждый процесс знает одно: система запускается ядром, и службы ядра находятся в распоряжении процесса в течение всего времени, которое он будет тратить на работу с ЦП. Благодаря этому процесс может запрашивать ядро о других процессах, выполняемых в качестве экземпляров одного и того же исполняемого файла. Первое решение, которое приходит мне на ум - прочитать виртуальную файловую систему /proc .Этот FS действует как интерфейс между пользователем/приложением и ядром (поскольку эти файлы представляют структуры ядра и данные). В этой файловой системе каждому процессу присваивается каталог (с именем PID), и в этом каталоге вы найдете ссылку с именем exe . Например, вот мой каталог bash process ', PID 22343:
lrwxrwxrwx /proc/22343/exe -> /bin/bash*
Теперь, просматривая файловую систему, вы сможете найти процессы, которые выполняют один и тот же исполняемый код, то есть процессы, для которых ссылка exe предназначена для одного и того же исполняемого файла.
Однако, поскольку все системы Unix не реализуют /proc одинаково, разработчики стремятся использовать более портативное решение, которое полагается на то, что практически все системы Unix понимают: обычные файлы. Это то, для чего обычно используются файлы .pid .
Чаще всего эти файлы можно найти в /run . Например:
-rw-r--r-- /run/acpid.pid
-rw-r--r-- /run/atd.pid
-rw-r--r-- /run/crond.pid
Эти файлы создаются приложением, которому они принадлежат, и используются в качестве маркеров того, выполняется ли экземпляр программы. Обычно содержимое этого файла просто состоит из PID выполняемого процесса. В этом случае выполняется процесс acpid с PID 1503, и именно это находится в файле PID.
Теперь, поскольку все процессы одной и той же программы совместно используют один и тот же код выполнения, они совместно используют свои константы (по крайней мере, их значения). По этой причине, если каждый экземпляр знает, где искать файл PID, программирование одноэкземплярной программы достаточно просто:
if (the pid file exists) then
send a signal to the running process or just bring it on the foreground
exit since the work is going to be handled by the already-running process
else
actually start the program, the first instance
endif
Использование сигналов в первом случае является поведением, которое я видел больше всего, однако, если ваше приложение использует некоторые более сложные IPC (сокеты, очереди сообщений,...), вы можете использовать его, чтобы сообщить ему, что пользователь запросил что-то, что ему нужно сделать.
-121--210060- Изначально несколько процессов могут выполняться с одним и тем же исполняемым кодом . Если это не происходит естественным образом, то да, программа сама сделала это. Однако я не смог рассказать вам, как это делается в системе Windows (или, по крайней мере, вполне похожей на Windows). В Linux мы в основном используем файлы .pid .
Это происходит из-за того, что exe-файл работает как сервер?
На самом деле есть вариант, который позволяет это в Emacs. Тем не менее, я не совсем вижу смысл для просмотра PDF... В системе Linux я могу придумать два широко используемых решения для этого:
- Сокет UNIX, который позволяет двум экземплярам общаться.
- Сигналы: когда рождается второй экземпляр, он просто посылает сигнал первому (говоря: Проснись! ) и выходит.
Первое, что вы можете проверить: можно ли это настроить? На VLC, например, это можно установить (и это довольно потрясающе):
По какой-то причине (которую я не очень хочу открывать), я не могу больше запускать Wine. Однако в виртуальной машине я пришел к ним в меню Edit > Preferences :
Переключение на Один документ и разрешение Несколько экземпляров должны превратить эту мелочь в средство просмотра PDF, которое вы ищете!
В системе Linux можно попытаться воспроизвести файл .pid , созданный приложением. Это может привести к неприятным результатам, но если вы удалите файл после запуска приложения, вы должны уловить новый экземпляр, если он не ищет другие экземпляры дальше файла .pid .
Другим решением является запуск второй программы в качестве другого пользователя, поскольку два пользователя не могут совместно использовать один и тот же процесс, программа должна запускаться дважды. Вот как некоторые люди успешно запускают Skype дважды в Linux (хотя это не требует так много усилий).
Возможно, необходимо иметь в виду, что приложение, работающее в одинарном режиме, вероятно, имеет веские причины для этого. Кроме того, большую часть времени, это выбор пользователя больше, чем фактически необходимый дизайн.
Достоинства
Выполняются только один процесс, что означает одно адресное пространство памяти для всех, и, следовательно, простой коммуникационный между двумя процессами, двумя экземплярами .
Некоторые графические программы выполняются очень часто. Возьмем пример VLC: каждый раз, когда я открываю файл MP3 в моем каталоге Music, он создает новое окно! То есть каждые 3 или 4 минут, когда музыка заканчивается, я должен закрыть старое окно, и открыть новый файл. Это не удобно. Вообще. Однако, если текущий экземпляр VLC зарегистрирует следующую песню в своей очереди без закрытия/повторного открытия, это аккуратно.
Еще одно преимущество: используйте сверхтяжелое приложение, как модную видеоигру. Это приложение требует много времени и ресурсов для запуска, и мы все знаем, как легко случайно запустить приложение по ошибке. Если приложение запущено в одинарном режиме, его перезапуск обычно приводит к возвращению первого экземпляра на передний план. Многие разработчики игр также используют это, чтобы запретить пользователям входить в систему с несколькими учетными записями одновременно.
Недостатки
Ну, как видите: тенденция к плохому дизайну. Действительно, поскольку это делает связь намного проще (без необходимости межпроцессной связи, IPC), некоторые ленивые разработчики могут пытаться заставить свои приложения постоянно переводить в состояние одного экземпляра. Для большинства приложений это не проблема, но для просмотра PDF, это смешно.
Нет на самом деле мошенничество, но плохой сценарий: не предлагая это как вариант. Если приложение действительно не должно работать в одинарном режиме, следует всегда делать выбор пользователя (или просто использовать несколько экземпляров, когда это не беспокоит).
Однако основная проблема здесь - пользовательский опыт . Вот почему режим одного экземпляра часто является опцией, потому что он действительно зависит от того, как вы используете программу. Если вы просто смотрите 1 или 2 видеофайла в месяц,вероятно, вас не волнует, что VLC работает в нескольких экземплярах. Если вы слушаете музыку 100% время, вы заботитесь об этом, потому что вы не хотите закончить с n VLC процессов, с n-1 неактивных.
В общем, нет. Если программа никогда не вызывает execve, у вас нет возможности что-либо перехватить, если только вам не удается написать код для презагрузки над символом, но я не уверен, что это работает даже с WINE.