Я скопировал этот вопрос сюда из StackOverflow ...
Я установил incron из репозитория EPEL (0.5.9) (прежде чем вы спросите; ДА, я также попытался загрузить исходный код и скомпилировать локально (0.5.10); те же результаты) и пытаюсь настроить процесс на моем CentOS 6.4. (последний) виртуальный ящик, который я успешно прототипировал на своей локальной машине Ubuntu 12.04 (процесс, включающий incron
отлично работает под Ubuntu):
Некоторая информация заранее:
visudo
чтобы обойти некоторые проблемы с разрешениями ...Я попытался применить политику для incron, как описано здесь http://blog.siphos.be/2013/05/a-selinux-policy-for-incron-finishing-up/ но я продолжаю получать
libsepol.policydb_read: policydb magic number 0x696c6f70 does not match expected magic number 0xf97cff8c or 0xf97cff8d
semodule_package: Error while reading policy module from incron.te
когда я пытаюсь использовать semodule_package
Я попытался определить среду как в самом скрипте, так и в пре-скрипте caller.sh
делая это, я могу env > /tmp/envfile.txt
что указывает на то, что скрипт работает в клоне sudo env
(как я и предполагал), однако я до сих пор не получаю вывода от моего скрипта, либо работа, которую он должен выполнять с входным файлом, либо любой из его журналов ...
это должны быть разрешения, верно? (Я примерно на один день вдали от того, чтобы просто сделать chmod -r 777
в корневой файловой системе;))
В Ubuntu 12.04 простое действие: sudo incrotab -e
и вход /tmp/ IN_CREATE,IN_NO_LOOP env > /home/username/envfile.txt
показывает, что incron уже запущен в среде root / sudo, как предполагает документация incron.
Это все, что связано с SELinux, или в CentOS происходит что-то еще, что усложняет задачу?
Если я вызываю свой сценарий из командной строки с помощью sudo /path/to/my/script.sh arguments
Работает как часы.
или если на то пошло, если я вызову caller.sh
все работает нормально, но когда caller.sh
вызывается incrond
это то же самое, даже не могу env > /dev/pts/0
от него. (хотя я ЖЕСТЯНАЯ БАНКА env > /tmp/envfile.txt
sudo service incrond status
проверяет, что incrond запущен. root и myusername добавляются в /etc/incron.allow
, /etc/incron.deny
пусто.
Мой incrotab для root:
/path/to/dropfolder/ IN_CLOSE_WRITE sudo /path/to/my/script.sh $@/$#
События в /path/to/dropfolder/
привести к НИЧЕМУ полезному. журналы создаются в / var / log / cron, никаких сообщений и никаких действий с файлами в папке не происходит.
Итак, я исследовал: было предложено cron
работает в минимальной среде, и для выполнения сложных команд / сценариев вам, возможно, придется выполнить свой .bashrc
и / или экспортируйте свой PATH в начале команды cron.
Редактировать: В документации указано, что incron
запускать из системных таблиц или root берет env из своей среды хоста, поэтому только incron
для выполнения пользователями без полномочий root должны потребоваться какие-либо действия с env или PATH
Итак ... incrontab для root:
/path/to/dropfolder IN_CLOSE_WRITE . /home/myusername/.bashrc; export PATH=$PATH:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin; sudo /path/to/my/script.sh $@/$#"
Нет кубиков… пробовал &&
вместо того ;
= нет кубиков. Если вы можете придумать вариант вышеизложенного, я, наверное, пробовал ...
Итак, давай попробуем немного restorecond -R /usr/sbin/incrond /etc/incron*
действие! Ха, там тоже никаких изменений. service incrond stop
с последующим service incrond start
а потом service incrond restart
… Нет, нет и нет.
Кардинальные меры: yum remove incron
и yum install incron
, chkconfig incrond on
а затем для хорошей меры sudo reboot
!
как насчет старины touch ./autorelabel
и перезагрузка? Нет!
Ничего.
Я даже ничего не получаю от /tmp/ IN_ALL_EVENTS echo boo> > /home/myusername/boofile.txt
, следовательно, моя неспособность даже env > envfile.txt
проверить, есть ли incron
работает в разреженной среде… (см. примечание выше)
И все еще: service incrond status
дает incrond (pid xxxx) is running...
дальнейшее изучение /var/log/cron
дает такие результаты: Aug 14 15:05:30 hostname incrond[1584]: (root) CMD (sudo /path/to/DropFolder/script/subfolder/script-Beta-1.sh /home/username/DropFolder/testfile.file)
-да, я убедился, что мой скрипт исполняется ..
если я установлю root в incrontab, чтобы он содержал /tmp/ IN_ALL_EVENTS,IN_NO_LOOP env > /tmp/envfile.txt
Я ничего не получаю. хвостик /var/log/cron
содержит: Aug 15 10:06:32 hostname incrond[1584]: (root) CMD (env > /tmp/envfile.txt)
но файл не существует в /tmp/
так что incrond действительно пытается сделать ЧТО-ТО, но я нигде не получаю вывода ... даже echo > /dev/pts/0
дает нада результаты.
если я сделаю рут incrontab
/tmp/ IN_ALL_EVENTS,IN_NO_LOOP . ./home/print/.bashrc; env > /tmp/envfile.txt
как было предложено в ряде тем, которые я обнаружил, имея дело с cron
проблемы окружающей среды я получаю Aug 15 12:30:25 hostname incrond[1726]: cannot exec process: Permission denied
в pid
здесь отличается от того, который утверждает, что он выдал команду, поэтому, очевидно, здесь происходит порождение какого-то дочернего процесса ... это было упомянуто в ссылке на политику SELinux выше, и я чувствую, что они связаны, но не должны быть PREMISSIVE и DISABLED Настройки SELinux не заботятся об этом ??
прежде чем я попытался установить SELinux в состояние ОТКЛЮЧЕН, я получал записи в /var/log/audit/audit.log
это указывало на то, что incron пытается что-то сделать, и они res=success
в конце ... что, кажется, означает, что SELinux позволял чему-то происходить, но ничего не происходит! После установки SELinux на ОТКЛЮЧЕНО и обратно на РАЗРЕШЕНИЕ и перезагрузки (несколько раз) я не получаю никаких записей в /var/log/audit/audit.log
связанные с incrond помимо service start
и т.д. связанные вещи. WTH?
Я испробовал все описанные выше тактики incron как root (sudo incrontab
), как обычный пользователь, и хотя системные таблицы (расположенные в /etc/incron.d
) с теми же результатами: p
Я бросил в это кухонную раковину (насколько я понимаю ее содержимое) и не могу найти решение ... Что мне не хватает? Я надеюсь, что кто-нибудь сможет заставить меня почувствовать себя идиотом в короткие сроки!
Я была такая же проблема. После долгих проб и ошибок я обнаружил, что моя исходная линия
/path/to/watch IN_CLOSE_WRITE /usr/local/bin/mycommand $@/$#
не работает, но работает следующее:
/path/to/watch IN_CLOSE_WRITE /bin/sh /usr/local/bin/mycommand $@/$#
Я предполагаю, что incron не выполняет сценарии с shebang (пока?) И нуждается в интерпретаторе внутри команды.
edit: после небольшого дополнительного тестирования я обнаружил, что если команда является сценарием (bash или shell), ей потребуется расширение .sh или к ней нужно добавить интерпретатор, например / bin / sh. Таким образом, оба следующих примера будут работать (по крайней мере, под CentOS 6.4)
/path/to/watch IN_CLOSE_WRITE /bin/sh /usr/local/bin/mycommand $@/$#
/path/to/watch IN_CLOSE_WRITE /usr/local/bin/mycommand.sh $@/$#
Хорошо, вот ответ:
Несмотря на всю документацию, я могу найти заявление об обратном, incrond
под CentOS 6.4 работает в разреженной среде и ведет себя как cron
. это НЕ относится к Ubuntu, где incron наследует свою среду от root для системных таблиц и корневых таблиц, и только пользовательские таблицы работают в разреженной среде. Это, конечно, означает, что если вы вызываете сценарий (я), сценарий должен создать среду, и у каждой вещи должен быть полный путь. ВСЕ. (ну, кроме встроенных команд оболочки: p)
многочисленные поиски Google, Bing и Stack Overflow и Server Fault сказали мне, что cron
действует таким образом, но все они, кажется, также указывают на то, что incron
работает, как описано в документации, которая ДЕЙСТВУЕТ в Ubuntu ...
Итог, теперь он работает, ура!
(это не решает мою проблему с применением политики безопасности SELinux для incron
, но об этом я позабочусь позже, в другом посте ...)
Из-за недостаточной репутации мой вклад представляет собой отдельный ответ, а не комментарий к user199085.
Да, OP говорит CentOS, но для людей Ubuntu мне также пришлось придерживаться sudo -u my_user_name
перед bin/sh
немного. Итак, линия становится
/path/to/watch IN_CLOSE_WRITE sudo -u my_user_name /bin/sh /usr/local/bin/mycommand $@/$#
Сообщение incrond: cannot exec process: Permission denied
Попробуйте добавить Икс разрешение на выполнение сценария (это разрешение могло быть «удалено» ftp
, sftp
, и т.д.)
chmod +x /srv/datadisk01/your/incron_script.sh