LINUX.ORG.RU
ФорумAdmin

глюки крона в slackware


1

2

наблюдается «несоответствие» переменных окружения, по порядку

по идее, переменные оеружения (PATH,SHELL,TERM,MAILTO,HOME etc...) должны определятся в след. порядке:

- из окружения пользователя
- из окружения крона пользователя  (если определены в кроне)
- из окружения запущенного скрипта (если определены в скрипте)

во всяком случае при настройке крона в дебиане я не замечал какого либо «неудобства» или «несоответствия данным правилам»

данные правила «не где то вычитанные - а эмпирически выстраданные» :о)

в слакваре постоянно натыкаюсь на грабли

для отладки данной задачи - из крона запускаю скрипт «cron_test.sh», который выводит переменные в файл «cron_test.log»

ниже рассмотрены 3и случая и соотв. содержимое лог-файла

// крон   - переменные закоментированы
// скрипт - переменные закоментированы
SHELL  = /bin/sh
PATH   = /root/bin:/sbin:/usr/sbin:/usr/local/sbin:/bin:/usr/bin:/usr/local/bin
TERM   = xterm
MAILTO =.
HOME   = /home/usr
// крон   - переменные разкоментированы
// скрипт - переменные закоментированы
SHELL  = /bin/sh
PATH   = /root/bin:/sbin:/usr/sbin:/usr/local/sbin:/bin:/usr/bin:/usr/local/bin
TERM   = xterm
MAILTO =.
HOME   = /home/usr
// крон   - разкоментированы
// скрипт - разкоментированы
SHELL  = /bash_user
PATH   = /PATH_USER
TERM   = term_user
MAILTO = mailto_user
HOME   = /home_user

итого :

первые два случая - "идентичные результаты" (косячные)
третий случай     - "самый правильный"

если переменные не определены ни в кроне ни в скрипте:
  PATH - root-овый

если переменные определены в кроне:
  переменные вообще не соот. определенным в кроне:

если переменные опеделены в скрипте:
  переменные "правильные"

т.е. «самый главные» - первые два случаю - косячные

(натыкался на это постоянно, когда хотел в крон-файле использовать команду_имя_скрипта, без полного пути, расчитывая на адекватное определение PATH)

проверено

- Sklackware 12.2 / 14.1 (глюки присутствуют)
- Debian 5.0.10 / 7.0.5  (правильное поведение)

выслушаю комментарии, можно ссылки, мысли, кто как с этим борется спасибо

...

содержимое файлов (крон и скрипт)

//
// /var/spool/cron/crontabs/usr
//

PATH=/PATH_CRON
SHELL=/bash_cron
TERM=term_cron
MAILTO=mailto_cron
HOME=/home_cron

<далее идут команды крона>
//
// cron_test.sh
//

#!/bin/sh

PATH=/PATH_USER
SHELL=/bash_user
TERM=term_user
MAILTO=mailto_user
HOME=/home_user

LOG=/home/usr/var/log/cron_test.log
echo "
SHELL  = ${SHELL}
PATH   = ${PATH}
TERM   = ${TERM}
MAILTO = ${MAILTO}
HOME   = ${HOME}
" >> $LOG
👍

Последнее исправление: sunjob (всего исправлений: 2)

Почему бы не написать самим разработчикам слаки? Думается, сам Патрик вполне может ответить что к чему, в последнее время популярность слаки на нуле, правда, Docker даёт слаке вторую жизнь - очень удобно иметь полноценный докер контейнер размером в 85 мб :)

menangen
()

в дебиане

Трёхзначный патчлевел ни о чём не говорит? Везде, где это недоразумение ещё используется, оно собирается с уникальным набором патчей поверх релиза 1993 года.

Gotf
()

UPDATE 2014.11.23

согласно ману крон устанавливает 4е переменные окружения

USER, LOGNAME, HOME, and SHELL

на деле они берутся из пользовательского окружения (в топике рассмотены только две из них, но и при детальном рассмотрении видно что они так же - берутся из пользовательского окружения и не из крона)

по сути, вообще ни одна переменная не устанавливается кроном, переопределить переменные окружения можно ТОЛЬКО В СКРИПТЕ

проверить это можно так же добавить в кронтаб и скрипт эти переменные (что и было сделано) - и провести «тестовый замер»

...

если у вас все отлично работает, то, пожалуйста, выложите ваши скрипты, логи, подробне описание системы-осн.библиотек, патчей итд

...

по поводу

во всяком случае при настройке крона в дебиане я не замечал какого либо "неудобства" или "несоответствия данным правилам"

данные правила "не где то вычитанные - а эмпирически выстраданные" :о)

дебиан был указан как самый распространенный и естественно пользуемый (настраиваемый) в своем кругу

а правило поведение - обычное UNIX поведение крона, проверено на большом количестве дистрибьютивов, наверное более 15, и в частности, за последнее время проверено на след. настраиваемых системах:

linux-mint-16 
altlinux-6.0.0 
kali-linux 1.0.1 
open suse 12.3 
pclinux-2011.08 
ubuntu-10.04 
fedore-19 

и ни где не было какого либо отклонения от правила, поэтому у меня не было даже намека на мысль что в !!! СЛАКЕ !!! будет сделано как то иначе (уж где-где, но не в слаке)

...

итого:
- глюк еще раз подтвердился 
- если я что то неправильно понимаю, поправьте

спасибо

sunjob 👍
() автор топика
Ответ на: комментарий от Pinkbyte

В Debian он только в experimental, но и там явно заброшен. В данный момент выбор невелик:

systemd-cron 1.3.1+ds1-2
cron 3.0pl1-127
bcron-run 0.10-3
Первый сыроват, со вторым всё понятно, а третий тянет за собой runit, что, впрочем, не проблема.

Gotf
()
Ответ на: комментарий от Gotf

а третий тянет за собой runit, что, впрочем, не проблема.

Если это тот же bcron, что и sys-process/bcron, то это странно:

pinkbyte@phantom ~ $ emerge bcron -pv 
^[[24~
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] dev-libs/bglibs-1.041  310 KiB
[ebuild  N     ] sys-process/daemontools-0.76-r7  USE="(-selinux) -static" 44 KiB
[ebuild  N     ] sys-apps/ucspi-unix-0.36-r3  14 KiB
[ebuild  N     ] virtual/daemontools-0  0 KiB
[ebuild  N     ] sys-process/bcron-0.09  57 KiB
[blocks B      ] sys-process/cronie ("sys-process/cronie" is blocking sys-process/bcron-0.09)
[blocks B      ] sys-process/bcron ("sys-process/bcron" is blocking sys-process/cronie-1.4.11-r1)

Блокировка понятна, куски runit-а вроде не обнаружены...

Pinkbyte 👍
()
Ответ на: комментарий от Gotf

А что означают упоминания daemontools?

Runit is a «reimplementation» of the «seminal» daemontools

Ок, убедил

Pinkbyte 👍
()
Ответ на: UPDATE 2014.11.23 от sunjob

Обслуживанием crontab-ов в Slackware занимается dcron. В его документации английским по фоновому написано: dcron не устанавливает переменных окружения, если вам это нужно, сделайте это сами в сценарии, а чтобы не плодить процессов — exec в помощь.

В man crond от dcron-а написано, что 4 переменных окружения пользователя он из окружения сценария не удаляет и они дойдут до сценария. Никаких других переменных никто не обещал.

Откуда, скажите на милость, эта истерика про глюки? Не устраивает вас dcron, соберите и поставьте тот, к которому привыкли в Debian-е, никто не запрещает, будет и тут как привыкли там.

А глюки чтения и перевода документации да, исправлять надо.

bormant
()
Ответ на: комментарий от menangen

Не может. Он оперирует периодами в днях, не меньше.

Gotf
()
Ответ на: комментарий от sunjob
This cron daemon sets up only four environment variables: USER, LOGNAME, HOME, and SHELL

именно «set up» а не «pass» т.е. «устанавливает» а не пропускает...

если я не прав, то «отредактируйте» а не «критикуйте» :о)

sunjob 👍
() автор топика
Ответ на: комментарий от sunjob

Посмотрите в исходники dcron-а, их там с гулькин клюв.

setenv() зовется только в одном месте в chuser.c, в котором 61 строка.

bormant
()
Ответ на: комментарий от bormant

тема исчерпана

тема исчерпана, спасибо!

sunjob 👍
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.