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>
