Hi Thomas, The issue with bcron appears when you switch from oldstable to stable, doesn't it?
Maybe it comes from a fuzzy integration of bcron with systemd. Have you tried to switch back to SysVinit? Here is an e-mail thread about switching Bullseye to SysVinit, which is two years old: https://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2019-August/002351.html Please can you check whether bcron behaves better when managed by SysVinit? Thank you in advance for your feedback. Best regards, Georges. Tomas Hodek a écrit : > Hi > > about acl, it is strange, since package acl was not installed (thought this > package is required to manipulate acl) > > this was all tested on current stable version (0.11-9) > > getfacl crontabs/ > # file: crontabs/ > # owner: cron > # group: cron > # flags: --t > user::rwx > group::--- > other::--- > > permissions before bcron install: > drwx-wx--T 2 root crontab 4096 Feb 22 2021 crontabs > > so I chaneged them to: > drwx-----T 2 cron cron 4096 Sep 27 08:27 crontabs > > > > After upgrade to debian/testing acl changed: > > getfacl crontabs/ > # file: crontabs/ > # owner: root > # group: crontab > # flags: --t > user::rwx > user:cron:rwx > group::-wx > group:cron:rwx > mask::rwx > other::--- > > > However I still get error in syslog: > > daemon: bcron-start: client (pid 798) exited with 111 status, exiting > > Also tried to chown whole directory as mentioned, but issue remains same. > > > > > ========== > > Our issue with cron was not yet reported, since I did not found any > regularity and have no test environment where I was able to reproduce this > issue. Only thing I know for sure is the fact that cron process sometimes > eats 1 whole CPU core and then jobs are not being executed correctly. Normal > CPU usage is mere percents. Restart of daemon fixes it. > > > Tomas > > > On 26. 09. 22 19:01, Georges Khaznadar wrote: > > Hi Thomas, > > > > thank you for your investigation work. > > > > The modifications which I made, since version 0.11-9 which was > > maintained by Dmitri Bogdanov, are aiming to prepare a transition from > > cron (whose upstream is no longer maintained) to cronie (not for > > tomorrow, but at some time later). For such a transition to be feasible, > > all cron equivalents used in debian must share a common base, so now > > bcron depends on the package cron-daemon-common (like cron). > > > > However, bcron has a peculiarity: the directory > > /var/spool/cron/crontabs/ must be given to user cron and group cron, > > while other cron-like packages give this directory to user root and > > group crontab. > > > > In order to let users install cron-like packages back and forth, > > postinst and prerm routines of bcron are modifying access control lists > > (ACLs) when bcron is installed and when it is purged. > > > > From what you wrote, I suspect that the access control lists are not > > correctly tuned, so, maybe, schedulers cannot do exactly the same job > > when launched by systemd than when they are launched manually. > > > > I fair that the difference list between versions 0.09-13 and 0.11-17 > > may be too long to be useful. Please can you check whether the version > > 0.11-9 available in debian/stable can currently fulfill your needs? > > > > Another question, if you do not mind: please try to install the last > > version from testing (0.11-17), then make a: > > > > # chmod -R cron:cron /var/spool/cron/crontabs/ > > > > and check whether this can fix the spurious behavior? > > > > Thank you in advance for your feedback. > > > > ===================================== > > > > By the way, you wrote that you had been "forced to install bcron instead > > of default cron package since the default one sometimes failed to > > execute all configured jobs" ... > > > > Did you post bug reports about it, against cron? This package, whose > > popcon score is two thousand bigger than bcron, has a list of 87 open > > bugs. I began to fix a few of them four months ago, and my progress is > > slow, because I want to write a test for each bug I fix, in order to > > prevent regressions in the future. > > > > The page > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=cron > > does not allow me to view precisely whether some of the bug reports come > > from you. I you have reported some, please tell me which they are. > > > > Best regards, Georges. > > > > > > > > > > Tomas Hodek a écrit : > > > Hi Georges, > > > > > > I have tried to enter log messages as requested (also included header > > > files > > > for syslog library), recompiled etc... But i am not able to get any > > > relevant > > > informations from syslog - nothing is written. Am I missing something? > > > > > > I have also made fresh install of debian 11 and even with no additional > > > software bcron-start is exitting with 111 status. > > > > > > When upgraded to testing release same problem: > > > > > > apt-cache policy bcron > > > bcron: > > > Installed: 0.11-17 > > > Candidate: 0.11-17 > > > Version table: > > > *** 0.11-17 550 > > > 500 http://deb.debian.org/debian testing/main amd64 Packages > > > 100 /var/lib/dpkg/status > > > 0.11-9 500 > > > 500 http://deb.debian.org/debian bullseye/main amd64 Packages > > > > > > > > > Tomas > > > > > > On 24. 09. 22 17:23, Georges Khaznadar wrote: > > > > Dear Thomas, > > > > > > > > can you give me more information? The error code 111 can be throwed from > > > > many parts of bcron's code, as you can see by launching > > > > `grep 111 *.c` in the directory of bcron's source. Most errors come with > > > > an informative string, like ... > > > > bcron-update.c: die1sys(111, "Could not change directory"); > > > > > > > > Some of them do not come with an extra string: > > > > ---------------------8<-------------------------------------- > > > > $ grep -n "111)" *.c > > > > bcron-exec.c:69: exit(111); > > > > bcron-exec.c:85: exit(111); > > > > bcron-exec.c:136: die_oom(111); > > > > bcron-exec.c:139: exit(111); > > > > bcron-exec.c:385: die_oom(111); > > > > bcrontab.c:135: die_oom(111); > > > > bcron-update.c:147: die_oom(111); > > > > bcron-update.c:216: die_oom(111); > > > > crontabs.c:45: die_oom(111); > > > > job.c:34: die_oom(111); > > > > job.c:40: die_oom(111); > > > > ---------------------8<-------------------------------------- > > > > > > > > Unfortunately, I could not reproduce the bug you are describing. Maybe > > > > you can help me? It should be possible to send some message to syslog > > > > just before lines like bcron-exec.c:69:, bcron-exec.c:85:, and so on, by > > > > recompiling bcron-exec.c with some changes, like: > > > > > > > > syslog(LOG_ERR, "Hello, this is line 69"); exit(111); > > > > instead of : > > > > exit(111); > > > > in file bcron-exec.c, line 69, and so on. > > > > > > > > Then you should know better the reason why schedulers' child fails. > > > > > > > > Thank you in advance for any information about it. > > > > > > > > Best regards, Georges. > > > > > > > > Tomas Hodek a écrit : > > > > > Package: bcron > > > > > Version: 0.11-9 > > > > > Severity: important > > > > > > > > > > Dear Maintainer, > > > > > > > > > > init script /etc/init.d/bcron-sched should start schedulers, but > > > > > child fails with 111 status code. When launching > > > > > /usr/sbin/bcron-start manually from terminal it runs successfully. > > > > > Only relevant thing in syslog is: > > > > > daemon: bcron-start: client (pid 2363945) exited with 111 status, > > > > > exiting > > > > > > > > > > We have about 800 user crontabs in system, if it matters anything. On > > > > > some older machine, we are using version 0.09-13 without any issues. > > > > > However in the past we were also forced to install bcron instead of > > > > > default cron package since the default one sometimes failed to > > > > > execute all configured jobs. (bcron had no such as issue) > > > > > > > > > > -- System Information: > > > > > Debian Release: 11.4 > > > > > APT prefers stable-updates > > > > > APT policy: (500, 'stable-updates'), (500, 'stable-security'), > > > > > (500, 'stable') > > > > > Architecture: amd64 (x86_64) > > > > > > > > > > Kernel: Linux 5.10.0-14-amd64 (SMP w/50 CPU threads) > > > > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > > > > > LANGUAGE=en_US:en > > > > > Shell: /bin/sh linked to /usr/bin/dash > > > > > Init: systemd (via /run/systemd/system) > > > > > LSM: AppArmor: enabled > > > > > > > > > > Versions of packages bcron depends on: > > > > > ii libbg2 2.04+dfsg-2.1 > > > > > ii libc6 2.31-13+deb11u3 > > > > > ii runit-helper 2.10.3 > > > > > ii sysuser-helper 1.3.5.1 > > > > > ii ucspi-unix 1.0-1 > > > > > > > > > > Versions of packages bcron recommends: > > > > > ii daemon 0.7-1 > > > > > ii postfix [mail-transport-agent] 3.5.13-0+deb11u1 > > > > > ii runit 2.1.2-41 > > > > > > > > > > Versions of packages bcron suggests: > > > > > pn anacron <none> > > > > > pn runit-init <none> -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70
signature.asc
Description: PGP signature
