为什么cron命令在日志中显示出码头容器中的命令,但没有实际运行?

发布于 2025-02-06 22:57:31 字数 2398 浏览 2 评论 0原文

dockerfile

FROM almalinux:8

# [... supervisord setup ...]

RUN dnf install -y \
    crontabs
RUN sed -ri '/-session(\s+)optional(\s+)pam_systemd.so/d' /etc/pam.d/system-auth && \
    sed -ri '/^[^#]/ s/systemd//g' /etc/nsswitch.conf
COPY $TEMPLATE_DIR/supervisord/crond.conf /etc/supervisord.d/crond.conf

crond.conf

[program:crond]
    command=/usr/sbin/crond -nsm off
    stdout_logfile_maxbytes=0
    stdout_logfile=/dev/stdout
    stderr_logfile=/dev/stderr
    stderr_logfile_maxbytes=0

syslog:

2022-06-13 18:39:07,939 INFO success: crond entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

crontab -e

*       *       *       *       *       touch /var/www/html/test.txt

syslog:

Jun 13 18:57:59 e60d29fd100e crontab[331]: (root) BEGIN EDIT (root)
Jun 13 18:58:15 e60d29fd100e crontab[331]: (root) REPLACE (root)
Jun 13 18:58:15 e60d29fd100e crontab[331]: (root) END EDIT (root)
Jun 13 18:59:01 e60d29fd100e CROND[334]: (root) CMD (touch /var/www/html/test.txt)

我认为文件从未触摸...代码>,运行一个绝对路径命令...什么都没有。但是,在等待了一点(更长)并用调试标志上运行cron之后,命令似乎确实运行了,但是随着5到50年代的延迟,命令延迟:

load_entry()...about to parse command
2022-06-13T16:17:01.352923611Z linenum=21
2022-06-13T16:17:01.352929349Z load_entry()...returning successfully
2022-06-13T16:17:01.352934854Z ...load_user() done
2022-06-13T16:17:01.352940748Z unlinking old database:
2022-06-13T16:17:01.352960040Z check_inotify_database is done
2022-06-13T16:17:01.352966537Z user [root:0:0:...] cmd="touch /var/www/html/test.txt"
2022-06-13T16:17:01.352972511Z [10] do_command(touch /var/www/html/test.txt, (root,0,0))
2022-06-13T16:17:01.352979069Z [10] main process returning to work
2022-06-13T16:17:01.352984792Z 

巨大的延迟似乎也堆积起来,我认为我假定的是排队的命令来运行,堆的生长永远更大:

root         335  0.0  0.0  69708  5188 ?        S    19:15   0:00 /usr/sbin/CROND -nsm off -x ext,sch,proc,pars,load,misc
root         336 94.4  0.0  69708  1440 ?        Rs   19:15   8:52 /usr/sbin/CROND -nsm off -x ext,sch,proc,pars,load,misc

... multiply 10x the 2 processes above after a few minutes ...

有什么线索为什么巨大的延迟和怪异的行为?禁用Crond上的Intifify(-i)并不能改善事物...我在想可能偏向问题吗?

Dockerfile

FROM almalinux:8

# [... supervisord setup ...]

RUN dnf install -y \
    crontabs
RUN sed -ri '/-session(\s+)optional(\s+)pam_systemd.so/d' /etc/pam.d/system-auth && \
    sed -ri '/^[^#]/ s/systemd//g' /etc/nsswitch.conf
COPY $TEMPLATE_DIR/supervisord/crond.conf /etc/supervisord.d/crond.conf

crond.conf

[program:crond]
    command=/usr/sbin/crond -nsm off
    stdout_logfile_maxbytes=0
    stdout_logfile=/dev/stdout
    stderr_logfile=/dev/stderr
    stderr_logfile_maxbytes=0

syslog:

2022-06-13 18:39:07,939 INFO success: crond entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

crontab -e

*       *       *       *       *       touch /var/www/html/test.txt

syslog:

Jun 13 18:57:59 e60d29fd100e crontab[331]: (root) BEGIN EDIT (root)
Jun 13 18:58:15 e60d29fd100e crontab[331]: (root) REPLACE (root)
Jun 13 18:58:15 e60d29fd100e crontab[331]: (root) END EDIT (root)
Jun 13 18:59:01 e60d29fd100e CROND[334]: (root) CMD (touch /var/www/html/test.txt)

I thought the file is never touched... tried also echo, running an absolute path command... nothing. But after waiting a little (longer) and running cron with debug flags on, it seems the command does get run, but with something like a 5s to 50s delay:

load_entry()...about to parse command
2022-06-13T16:17:01.352923611Z linenum=21
2022-06-13T16:17:01.352929349Z load_entry()...returning successfully
2022-06-13T16:17:01.352934854Z ...load_user() done
2022-06-13T16:17:01.352940748Z unlinking old database:
2022-06-13T16:17:01.352960040Z check_inotify_database is done
2022-06-13T16:17:01.352966537Z user [root:0:0:...] cmd="touch /var/www/html/test.txt"
2022-06-13T16:17:01.352972511Z [10] do_command(touch /var/www/html/test.txt, (root,0,0))
2022-06-13T16:17:01.352979069Z [10] main process returning to work
2022-06-13T16:17:01.352984792Z 

The huge delay seems to also pile up what I presume are queued commands to run, and the pile grows forever larger:

root         335  0.0  0.0  69708  5188 ?        S    19:15   0:00 /usr/sbin/CROND -nsm off -x ext,sch,proc,pars,load,misc
root         336 94.4  0.0  69708  1440 ?        Rs   19:15   8:52 /usr/sbin/CROND -nsm off -x ext,sch,proc,pars,load,misc

... multiply 10x the 2 processes above after a few minutes ...

Any clues why the huge delay and weird behavior? Disabling inotify (-i) on crond does not improve things... I'm thinking maybe a time skew issue?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文