tee
stdout
поток к оконечному устройству управления /dev/tty
.
(
exec 1> >(tee -a stdout.log)
: > stdout.log
#var="$(echo -e "one\ntwo" | tee /dev/tty | grep one)"
var="$(echo -e "one\ntwo" | tee -a /dev/tty stdout.log | grep one)"
echo "var=$var"
)
cat stdout.log
# one
# two
# var=one
Я нашел проблему. -C
переключатель командной строки я отправляю к php
, который должен был быть -c
. Я понятия не имею почему cron
не сообщал, что мне любым способом, уже не говоря о полезном способе (или как мне так или иначе удалось получить его в crontab
с капиталом C, но тестом это на CLI с нижним регистром), но выполнение его все снова и снова в CLI с коллегой, здесь действующим как моя обезьяна и внезапно, он был очевиден.
Теперь, как глупый я чувствую?
Ну, по крайней мере, это разрешено теперь и cron
счастливо запускает мой проклятый скрипт. Поблагодарите Вас все за всю свою справку.
Прежде всего, когда задание крона перестало работать, крон посылает электронное письмо. По умолчанию это владельцу задания крона. Таким образом, те электронные письма, вероятно, идут в cronuser@localhost или возможно root@localhost. Проверьте те электронные ящики. С другой стороны, можно указать, куда почта должна пойти путем помещения MAILTO=email@domain
наверху crontab файла. (На самом деле я вижу, что Вы помещаете MAIL=""
наверху Вашего crontab. По крайней мере, согласно man 5 crontab
на моей машине это должно быть MAILTO
. И Вы не хотите выбрасывать сообщения об ошибках при попытке выяснить, почему это не работает!)
Во-вторых, использование крона /bin/sh
. Набор SHELL=/bin/bash
(снова, наверху crontab), если Вы должны колотить расширения.
В-третьих, Вы не полностью протестировали полномочия. Необходимо сделать что-то как:
# su -s /bin/sh -u cronuser
$ touch /path/to/stdout.log
$ touch /path/to/stderr.log
$ cat /path/to/process.php > /dev/null
$ exit
полностью проверять полномочия. cronuser
мог пропускать +x на родительском каталоге, например. (Я предполагаю, что необходимо проверить/usr/bin/php также, но я предполагаю, что это нормально),
Можно также попытаться выполнить команду в минимальной среде:
# su -s /bin/sh -u cronuser
$ env - /bin/sh
$ /usr/bin/php -C /etc /path/to/process.php
видеть, работает ли это.
MAIL=""
и перенаправлял stdout
и stderr
. Будет удаление MAIL
строка, средняя, они переходят к моему локальному почтовому ящику без отсутствия хоста SMTP, являющегося проблемой? Строки, которые Вы даете для тестирования полномочий, примерно, как я создал два .log
файлы, fwiw. Спасибо, хотя; я попробую все это, когда я доберусь до офиса утром.
– Owen Blacker
07.02.2012, 22:33
cronuser
или root
и выполненный mail
без параметров. Надежда это может помочь.Сообщите нам... Если /bin/ls -> /bin/bash
, Вам, возможно, не понадобится SHELL=/bin/bash
. Можно также заменить >
>>
для перенаправления файла (например, в > /path/to/test.txt
) из-за set -C
. Очень хороший ответ => +1
– olibre
07.02.2012, 23:28
su -s /bin/sh cronuser
и так далее, как в этом ответе), и это работает хорошо. Это все еще не работает изнутри cron
, Тем не менее, даже после удаления MAIL=""
строка. Разочаровывающе, это не генерировало электронной почты также. Нет никакого файла в /var/spool/mail/cronuser
, таким образом, я пытался измениться MAIL
строка к MAILTO="blackero@localhost"
но это не заставляет это выполнять (или посылать мне электронное письмо) также. Я все еще в недоумении...
– Owen Blacker
08.02.2012, 14:05
crond
выполнение?Попробуйте одну из этих команд:
pidof crond
pgrep -l crond
ps caxf | grep -6 crond --color
вывод последней команды:
11881 ? S 0:00 \_ httpd
11882 ? S 0:00 \_ httpd
11883 ? S 0:00 \_ httpd
11884 ? S 0:00 \_ httpd
11885 ? S 0:00 \_ httpd
11886 ? S 0:00 \_ httpd
2098 ? Ss 0:01 crond #this 'crond' is in red
2125 ? Ss 0:00 sudoscriptd
2127 ? Ss 0:00 \_ sudoscriptd
2136 tty2 Ss+ 0:00 mingetty
2137 tty3 Ss+ 0:00 mingetty
2138 tty4 Ss+ 0:00 mingetty
2139 tty5 Ss+ 0:00 mingetty
crond
конфигурация?Проверьте Ваш /etc/rc.d/init.d
или /etc/init.d
или безотносительно файла запуска.
crond
конфигурация может перечислить отклоненных или/и разрешенных пользователей.
Вашему пользователю отказывают? Проверьте эти файлы:
/etc/cron.allow
/etc/cron.deny
Если оба файла отсутствуют, только базируются, позволяется.
Если cron.allow
отсутствует и cron.deny
пусто, затем всем пользователям разрешают по умолчанию.
Файл /etc/crontab
должно быть записываемым для корня только:
$ ls -l /etc/crontab
-rw-r--r-- 1 root root 255 Jul 15 2006 /etc/crontab
crond
сказать?Естественный способ получить информацию из crond
местная почта. crond
обычно использование sendmail
. Если sendmail
не доступно, возможно дать другую почтовую команду (CRONDARGS="-mmail"
).
Но на данном этапе, лучшее должно проверить непосредственно crond
журналы (ll /var/log/cron*
).
crond
Проблема может быть устранена при повторном заявлении crond
...
Если проблема все еще там, то перед другим перезапуском, давайте выполним его без init.d
или service
, и попробуйте другие опции:
sudo crond-p-x sch
И проверьте снова crond
файлы журнала...
pam
. Я открою новый вопрос (относящийся к этому) через мгновение.
– Owen Blacker
08.02.2012, 15:56
/bin/sh: /usr/bin/php /tmp/helloworld.php: No such file or directory
, который едва полезен. По крайней мере, я добрался, проклятая вещь отсортировала :) – Owen Blacker 10.02.2012, 20:15