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 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.