Dear Thomas,

I made a mistake, when I read your first bug report: as your APT policy
was based on 'stable', you were reporting about the current stable
version, 0.11-9.

So the misbehavior which motivates your report, was introduced before I
adopted the package. This is weird, since version 0.11-9 passed to
stable for one year, an no bug report was reported between 2020-03-18
when this version entered testing and 2021-08-14, when bullseye became
stable.

Please can you make a test with version 0.11-17, which is currently in
testing ? I would prefer a lot to fix the problem in the last version
(if it is still there), even if studying the version in bullseye may 
shed some light on the bug.

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

Attachment: signature.asc
Description: PGP signature

Reply via email to