Не создается pid файл
хорошо, я искал повсюду и потратил довольно много времени на установку, удаление, попытку различных вариантов, но безуспешно.
Я на Mac OS X Lion (10.7.3) и пытаюсь настроить Python, MySQL.
я успешно установил Python и MySQL через HomeBrew. Python работает отлично.
после установки MySQL я выполнил первые 2 шага-unset и mysql_install_db команды.
Теперь, когда я пытаюсь запустить mysql " mysql.сервер старт", я получаю следующую ошибку
- Brajeshwar Это мое имя пользователя на моей машине.
изменить 2012/09/18: As указал Кейн убедитесь, что mysql база данных правильно настроена, прежде чем делать что-либо еще. См."ошибка PID в mysql.запуск сервера?" для получения дополнительной информации.
оригинальный ответ хранится ради истории: Это, скорее всего, is проблема с разрешениями. Проверка /usr/local/var/mysql/*.err . Мой сказал:"!--11-->
мне тоже пришлось сделать это:
я обнаружил, что это была проблема с разрешениями с mysql папка.
решил это для меня.
Я закончил с полной переустановкой mysql, и это, наконец, сработало.
предупреждение это удалит все ваши базы данных, поэтому убедитесь, что сначала сохраните дампы.
у меня была эта проблема на mac 10.10.5 Yosemite
что я сделал, чтобы решить эту
cd /usr/local/var/mysql
sudo rm *.err && sudo rm *.pid
sudo reboot
sudo mysql.server start
ноябрь, 2014: Если вы получаете эту ошибку на MySQL 5.6.x на Mac OS X Mavericks или Yosemite и хотите использовать MySQL с PHP локально (/tmp / mysql.sock-это то, где PHP PDO ожидает найти файл носка), вот что исправлено для меня:
1) раскомментируйте строки файла конфигурации homebrew по умолчанию и отредактируйте, как показано ниже
BOXNAME - это то, что у вас есть в вашей системе Prefs -> Network в качестве уникального идентификатора для вашего компьютера в сети.
2) установить разрешения на всех файлах в MySQL datadir. Все они принадлежали [my_username]. MySQL очень придирчив к этому и отказывается создавать PID-файл, если он (пользователь _mysql) не владеет каталогом.
3) запустите MySQL с помощью скрипта bash helper/wrapper:
надеюсь, что это поможет. Если выше не работает для вас, попробуйте запустить двоичный файл mysqld_safe вручную в каталоге Cellar / mysql/VERSION_ / bin/ и проверьте, какие настройки (если это бежит)
если это работает, вы можете
и увидеть что-то вроде
Я не уверен, почему это сработало для меня, но это показывает, где я получил my.параметры конфигурационного файла cnf. Вы также можете использовать параметры командной строки, чтобы попытаться устранить неполадки при запуске mysqld вручную.
если вы запустите управление для запуска сервера MySQL с помощью mysqld_safe, вам, возможно, придется сделать это, чтобы закрыть его перед попыткой mysql.помощник сервера bash. Сопротивляться желание убить -9 [PID], потому что вы можете повредить свои данные.
у меня была такая же проблема на OS X El Capitan, вот последовательность команд терминала, которая исправила ее для меня.
удалить файлы ошибок (вам придется изменить путь в зависимости от вашей установки)
найдите информацию для процесса mysql, который все еще работает, и убейте его:
Если программе требуется разрешение на запись, как мне установить ее с помощью chown? В частности, какими должны быть разрешения программы foo для решения этой ошибки?
Если у вас есть программа, foo пытающаяся создать / записать файл, права доступа к foo двоичному файлу не имеют значения, но все, что от них требуется , - пользователь, с которым он работает .
В этом случае foo пытается выполнить запись в систему /var/run , которая принадлежит root и доступна для записи только пользователю root .
Таким образом, вам нужно будет запустить программу, sudo foo чтобы создать этот файл PID. Пожалуйста, примите во внимание последствия безопасности для запуска программы от имени пользователя root до того, как вы это сделаете .
если разрешение для двоичных файлов является чем-то вроде: rw-rr, тогда будет ли программа исполняемой, если я запускаю программу от имени пользователя root, то есть позволяю создать идентификатор процесса в / var / run?
@Ankit: если бинарный файл вообще не имеет разрешений на выполнение, он не будет «работать»; но все , что вы столкнетесь как корень будет в состоянии создать Pid Under /var/run
Общий подход: определить пользователя и группу процесса, пытающегося получить доступ к файлу. Это часто встречается в конфигурации программного обеспечения (такого как веб-серверы / почтовые серверы / . ), но если программное обеспечение уже работает, используйте это:
Найдите процесс, для которого вы хотите настроить права доступа. В первом столбце указывается, под каким именем пользователя он работает.
Это скажет вам, к каким группам принадлежит пользователь.
Измените владельца или группу файла в соответствии со службой.
Примечание 1: Поскольку вопрос указывает на то, что файл находится в / var / run /, я предполагаю, что доступ нужен только одному процессу, если это не так, вам не следует менять владельца или группу, но вы можете рассмотреть возможность добавления процесса 'пользователь в группе или создание новой группы для этого файла / папки.
Примечание 2: забавные вещи могут случиться с apparmor, который является системой безопасности: он может препятствовать записи процессов в файлы и папки, на которые они имеют (на уровне файловой системы) все необходимые права. С aa-status его помощью вы можете увидеть, является ли конкретное правило для вашего сервиса активным.
Я просто добавил создание папки непосредственно перед выполнением start-stop-deamon. Это работает, потому что сценарий обычно запускается от имени пользователя root при запуске. Он просто создает папку в / var / run и немедленно меняет владельца, поэтому можно записать PID.
В приведенном ниже примере я проверяю наличие подпапки / var / run, где я помещаю PID в качестве текущего пользователя run, в данном случае user 'pi' (так как я на малине).
Также проверьте эту ссылку, так как она была очень познавательна для меня: скрипт Python для запуска в качестве службы , однако он не охватывал проблему, обсуждаемую здесь.
Я часто вижу, что программы указывают файлы pid и lock. И я не совсем уверен, что они делают.
Например, при компиляции nginx:
Может кто-нибудь пролить свет на этот?
pid-файлы пишутся некоторыми программами для записи их идентификатора процесса во время их запуска. Это имеет несколько целей:
- Это сигнал другим процессам и пользователям системы, что эта конкретная программа запущена или, по крайней мере, успешно запущена.
- Это позволяет очень легко написать скрипт, проверить, работает ли он, и выполнить простую kill команду, если кто-то хочет завершить его.
- Для программы это дешевый способ узнать, не был ли предыдущий запущенный экземпляр успешно завершен.
Разумеется, наличие pid-файла не гарантирует, что этот конкретный идентификатор процесса работает, поэтому этот метод не на 100% надежен, но во многих случаях «достаточно хорош». Проверка наличия определенного PID в таблице процессов не является полностью переносимой в UNIX-подобных операционных системах, если только вы не хотите зависеть от ps утилиты, которую может быть нежелательно вызывать во всех случаях (и я считаю, что некоторые UNIX-подобные операционные системы В ps любом случае реализовать по- другому).
Файлы блокировки используются программами для обеспечения того, чтобы два (с хорошим поведением) отдельных экземпляра программы, которые могут одновременно работать в одной системе, не обращались к чему-то другому одновременно. Идея состоит в том, что прежде чем программа получит доступ к своему ресурсу, она проверяет наличие файла блокировки, и, если файл блокировки существует, либо выдает ошибку, либо подождите, пока она не исчезнет. Когда он не существует, программа, желающая «приобрести» ресурс, создает файл, а затем другие экземпляры, которые могут встретиться позже, будут ожидать завершения этого процесса. Конечно, это предполагает, что программа, «получающая» блокировку, фактически снимает ее и не забывает удалить файл блокировки.
Это работает, потому что файловая система во всех UNIX-подобных операционных системах обеспечивает сериализацию , что означает, что в любой момент времени происходит только одно изменение файловой системы. Вроде как блокировки с базами данных и тому подобное.
Это правильно, если только файл блокировки не удален вручную. VMWare Player демонстрирует это поведение, например, если VMWare Player дает сбой, вы должны удалить .lck файл в каталоге виртуальной машины, в противном случае он сообщит вам, что он используется, когда вы попытаетесь запустить его.
Я не думаю, что программы для Windows работают так. Единственные программы с таким поведением, которые я видел, это порты из Unix / Linux
LawrenceC, Re " Когда его не существует, программа, желающая" приобрести "ресурс, создает файл "; Но есть специальные функции, специально созданные для такой синхронизации. Почему бы не полагаться на эти функции вместо того, чтобы использовать «взлом файла»?
@Pacerier - таким образом, файлы блокировки, вероятно, чаще используются такими вещами, как сценарии оболочки или программы, которые могут взаимодействовать со сценариями оболочки, поскольку оболочки Unix / Linux очень легко взаимодействуют с файловой системой, в отличие от других примитивов синхронизации. Файлы также легко сохраняются в разных процессах. Высокопроизводительная программа, очевидно, предпочла бы использовать собственные примитивы ОС по сравнению с файлами для внутренней синхронизации или даже по сравнению с другими процессами, которые не являются оболочками.
Эти файлы часто используются демонами, которые должны запускаться в системе только один раз. Файл PID обычно содержит идентификационный номер процесса уже запущенной и запущенной программы, если таковая существует. Кроме того, когда он запускается, он создает файл блокировки. Пока существует файл блокировки, он не сможет запустить другой без вмешательства пользователя. Если файл блокировки существует, а идентификатор процесса, указанный в файле pid, не запущен, демон считается находящимся в «мертвом» состоянии, то есть он должен работать, но, вероятно, не из-за сбоя или неправильного завершения работы , Это может инициировать специальный сценарий запуска / перезапуска для некоторых программ. Правильное выключение приведет к удалению файла блокировки.
процесс запускается от имени юзера, но при старте не хватает прав на запись pid-файла в в каталог /var/run, т.к. запись разрешена только руту:
/var/run - симлинк на /run drwxr-xr-x 23 root root 900 Мар 14 14:10 run/
и процесс не может запуститься.
как можно обойти сабж?
Запустить от рута, записать в /var/run, сменить uid? Посмотри, как любой другой демон это делает
записывать pid туда, куда имеет доступ пользователь
это наверное не соответствует LFS?
Исходники же. Хоть вот polipo возми (взял наугад из /var/run. Он под собственным пользователем работает)
В /var/run лежат PID'ы не абы чего, а системных сервисов. А init-скрипт всегда стартует от root. Если хочется понизить привилегии, то скрипт может запустить дочерний процесс и записать его PID в нужный каталог. То есть основную работу выполняет пользовательский процесс, но его PID сохраняет рутовый.
Пиши в хомяка PID, нее?
/me тока так и делает.
Кстати, подкинул идею:
Это из distcc. Also:
Don't put the PID file in /var/run/foo.pid, put it in /var/run/foo/foo.pid and have /var/run/foo owned by user foo and group foo. That way you can delete the pid file before exiting and you don't have to raise your privilege level.
ну дык а что делать?
Ну а чтож поделать?
попробую в другой каталог pid-файл -> если будет работать - ну и ладно.
Так ладно, пошутили и хватит.
Зачем тебе именно в /var/run писать? Чем хомяк не угодил? И уже было сказано как писать в /var/run/.
ТЗ такое писать в /var/run(( хоть и было сказано-я не догоняю как писать в /var/run. установить polipo и по аналогии в его скрипте каком-то?
Я ж тебе уже 3 способа дал:
1) Пиши и понижай привилегии (man 2 setuid)
2) Создай pid-файл из инит-скрипта и сделай chown
3) Создай папку /var/run/yourdaemonname и сделай chown на ней
Don't put the PID file in /var/run/foo.pid, put it in /var/run/foo/foo.pid and have /var/run/foo owned by user foo and group foo.
Во-первых, вот это уж точно не соответствует FHS: «Applications must generally not add directories to the top level of /var. Such directories should only be added if they have some system-wide implication, and in consultation with the FHS mailing list.»
Ты читать умеешь?
Во-вторых, это что же, если пользователя зовут Опанасенко Пётр Тимофеевич
Ещё раз, мы говорим о ДЕМОНЕ, а не о ЧЕЛОВЕКЕ-ПОЛЬЗОВАТЕЛЕ. У ДЕМОНА часто бывает свой пользователь (который не может залогиниться, так как у него стоит nologin для логина, а хомяк прописан куда-нибудь в /nonexistent). Так делают для того, чтобы сложные демоны не работали от рута.
У ДЕМОНА часто бывает свой пользователь (который не может залогиниться
А вот об этом я и не подумал. Я думал о сессионных демонах, которые, например, запускаются от имени каждого пользователя, когда он логинится в в систему.
Да, тогда будет разумно создать в /var/run директорию для демона и там создавать PID-файл, наверное. Более того, FHS 2.3 говорит: «Programs may have a subdirectory of /var/run; this is encouraged for programs that use more than one run-time file.» FHS 3 (бета-версия) советует использовать /run вместо /var/run.
Либо сервис запускается от root, открывает пидфайл и сбрасывает привилегии, либо сервис запускается не от root, а pidfile сохраняет в поддиректории в /var/run с соответствующими владельцем и правами.
Задача демона или init script'a?
Кто должен заботиться о создании и удалении?
Демона в общем случае.
Демон убин kill'om, мои действия?
Вот, кстати, много придумывал: как обезопасить процесс и обеспечить однозначно уникальный запуск. Навелосипедил нечто вроде pgrep + чтение pid-файла. Потом навелосипедил улучшение этого велосипеда (если есть PID-файл, сначала проверяется, что за процесс имеет такой PID: если тот же, то второй процесс отваливается, если чужой — продолжается стандартная проверка по /proc)
PID-файл стал невалидным. Какие тебе еще нужны действия?
Простейший случай: если нет процесса с PID'ом, записанном в PID-файле, либо этот процесс — не наш, то пересоздать PID файл и работать. Но есть шанс, что у тебя что-то уже работает, а PID-файл кто-нибудь стер, например.
Нажали RESET, твои действия при буте?
Кто должен заботиться о создании и удалении?
О создании — демон. Но путь к PID-файлу задаваться — инитскриптом.
О проверке валидности и удалении — инитскрипт.
geekless ★★ ( 02.11.12 19:32:32 )
Последнее исправление: geekless 02.11.12 19:33:02 (всего исправлений: 1)
OK, т.е. в иделе я так понял - оба.
Если требуется суровая надежность - сделай пару процессов.
Не, требуется просто проконтроллировать, чтобы демон был только один. Есть другие методы?
Проверить наличие PID'а при запуске и решить, что это и нужно ли еще.
Как вариант: создать, открыть, unlink. Тогда файл пропадёт, когда процесс его использующий пропадёт.
если за создание/УДАЛЕНИЕ pid-файла — отвечает сам демон — то я совершенно не вижу каких-либо препятствий в том чтобы демон мог быть спокойно убит через kill .
главное это чтобы был НЕ ``$ kill -KILL`` (а обычный ``$ kill -TERM``)
когда демон получает системный сигнал о том что его убивают — то демон закрывается и САМ в это время подчищает за собой pid-файл. всё логично :)
Не катит. Файл должен быть видимым.
или может быть надо было дать ссылку эту:
А если его по kill -9 грохнули? Или он сам с сегфолтом каким-нибудь отвалился, либо от oom-killer'а по башке получил?
тогда то что я аписал не поможет :)
вот именно поэтому сейчас и внедряется везде SystemD .
..а не потомучто Леннарт якобы дружит с гипножабой :-)
Бред. Каждый демонописатель в ответе за того, кого приручил свой велосипед.
Свои варианты я выше приводил. Они работают и никаких зондов в задницу вставлять не надо.
да если подумать — то какого фига вообще демон должен заботится о своём собственном PID ?
демон должен просто работать. и уметь себя корректно завершать (когда его просят завершать).
ситуации с segfault — сервершенно не является компетенцией демона, который делает эти segfault . за разрешение таких ситуаций должен отвечать вышестоящщий демон сервис.
это точно также логично, как и логично не обращать внимание на segfault-ные ситуации во время создания/удаления PID силами самого демона.
какого фига вообще демон должен заботится о своём собственном PID?
Ничего себе. Если подумать, какого фига я должен заботиться о своем благосостоянии? Пусть меня озолотят! А я ничего ради этого не буду делать.
ситуации с segfault — сервершенно не является компетенцией демона, который делает эти segfault
Ага, отвалившийся после километра пробега кардан — не вина автомеханика дяди Васи.
Ага, отвалившийся после километра пробега кардан — не вина автомеханика дяди Васи.
а почему это его вина? наиболее вероятно — что был инцедент с неким хулиганом, который проник на автостоянку ОЧЕНЬ СИЛЬНО стучал жёстким диском по кардану.
. (а потом на этом жёстком диске — хулиган установил Linux.. но уже уже другая история :)).
по крайней мере мы знаем что автомеханник приложил все силы чтобы кардан не отваливался :)
(даже если окажется что ситуация с хулиганом оказалась вымышленной кемто :))
вобщем, мне кажется что я НЕ смогу тебе обяснить всю эту ЛеннартПоттерингвскую философию..
..её надо понимать. чуствовать.
она приходит сама к тебе, если захочет
Для этого надо мастдайку осилить ;)
кстате на МастДайке — SystemD не работает.. и поэтому если нужно запускать демон именно там — то как раз МастДай это именно то место где нужно тра..продумывать ситуации с различными неожиданными завершениями демона (Segfault) и его соответствующим отношением к PID-файлу..
..а вот святой GNU/Linux в лицце Поттеринга — всё упрощает. и делает логичным =(^_^)=
в генточке об этом может позаботиться start-stop-daemon, насчет других дистров не знаю, может он там тоже есть
ТОЧНО! я понял! ДА! нужно осилить весь геморой в венде, чтобы понять почему нужен SystemD
(вендовый геморой — этоже многократно-усиленный геморой старых UNIX-принципов. )
венда — она как лупа!
а зачем в винде PID-файл нужен-то? Там вроде как винда сама за сервисами следит
святой GNU/Linux в лицце Поттеринга
Ну ты и вендузятник.
В винде sc есть.
ну да, есть. А что хотел сказать анонимус - не понятно
Вообще не понимаю зачем нужны эти пиды? Ведь можно же просто сделать один раз символьное устройство которое работало бы по следующему принципу: при чтении из него отдавало количество процессов запущенных от данного бинарника (или скрипта). И при запуске демон должен прочесть из этого устройства цифру, а дальше в зависимости если число равно 1 (т.е. один процесс от этого файла в системе) то начать работу, а если больше то самоубитсама.
ды вы что?! обкурились все?!
для этого дела в операционной системе есть блокировочные файлы!
делаешь при запуске демона — по отношению к блокировочному-файлу (не файлу устройства, а блокировачному файлу!) — ЭКСКЛЮЗИВНУЮ-НЕ_БЛОКИРУЮЩУЮ блокировку.
. и в этом случае второй демон просто не сможет запустится.
что за костыли вы какието предлагаете? демон сам себя убивает если видит своего клона — ДЫ ЭТО ОХРЕНЕТЬ МОЖНО какой костыль!
PID-файлы вообще нужны не для того чтобы не было дубликатов демнов. а для других целей.
PID-файлы вообще нужны не для того чтобы не было дубликатов демнов. а для других целей.
Для того, чтобы скрипты знали PID демона?
А для предотвращения повторного запуска lock-файл, так?
Вот из - за таких вот умников потом когда падает демон, невозможно перезапустить его пока не удалишь эти файлы ручками
Для того, чтобы скрипты знали PID демона?
хотя да. PID-файл особо то не нужен. например. если есть шина dBus.
А для предотвращения повторного запуска lock-файл, так?
заниматься lock-файлом правда не обязан именно самому демону.
за него могут сделать это другие :) ..
например внутри скрипта по запуску:
$ flock -xn /run/my_daemon/lock /usr/bin/my_daemon
ну или вообще использовать SystemD и не париться об блокировачных файлах тогда
Гейтс, залогинся уже! Мы тебя раскусили :)
Вот из - за таких вот умников потом когда падает демон, невозможно перезапустить его пока не удалишь эти файлы ручками
блокирвачные файлы НЕ НУЖНО СПЕЦИАЛЬНО УДАЛЯТЬ . они могут существовать ВЕЧНО и это никак не мешает запускать программу МНОГО РАЗ ПОВТОРНО.
$ flock -xn ~/my_test_lock_file /usr/bin/gedit
(не удаляя файл ~/my_test_lock_file — попробуй много раз подрят позапускай эту строчку. )
Тут один тролль в треде сделал логичный коммент, а если демон упал, а файл остался. Проверять скриптом, есть ли всё ещё демон?
Забей на него, он тролль =)
Так что, мы пришли к тому, что файлы копятся? Как они потом удаляются?
Гейтс, залогинся уже! Мы тебя раскусили :)
если бы я был бы Гейстчом — ябы начал рассказывать что Венде для блокировачных файлов — существует специальная (сугубо виртуальная) файловая система..
. и называются они не «блокировачные файлы» а «именованные мьютексы» :)
ан нет! я всего лишь вам рассказывают про блокировачные файлы внутри сугубо-физической файловой системе /run/ . и не разу не произнёс слово «мьютекс» (хотя по смыслу это оно и есть, но только внутри файловой системы) .
в генточке об этом может позаботиться start-stop-daemon, насчет других дистров не знаю, может он там тоже есть
Как часть openrc, эту тулзень можно скомпилять подо что угодно. Да и другие варианты есть. В большинстве случаев своё приложение можно даже не учить демонизироваться и делать всякие сопутствующие церемонии, а выполнять это всё start-stop-daemon'ом или аналогом.
Так это не баг, там костыль предложен для неправильного использования. Форкаться для ухода в фон должен start-stop-daemon, а не запускаемый им демон, тогда и с пидфайлом никаких проблем не будет.
Форкаться для ухода в фон должен start-stop-daemon, а не запускаемый им демон..
Если уж доверяешь дело сторонней тулзе, то доверяй целиком. Не доверяешь — велосипедь всё сам. Да и проще так со всех сторон.
Не, требуется просто проконтроллировать, чтобы демон был только один. Есть другие методы?
Читайте также: