Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 679836

Summary: sys-fs/e2fsprogs-1.45.0-r1 with sys-process/dcron - /etc/cron.d/e2scrub_all uses usernames which dcron does no understand
Product: Gentoo Linux Reporter: Thomas Capricelli <orzel>
Component: Current packagesAssignee: Gentoo's Team for Core System packages <base-system>
Status: CONFIRMED ---    
Severity: normal CC: hlein, jbuchert+genbug, s
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: Add a +cron USE flag, work around dcron incompatibility

Description Thomas Capricelli 2019-03-09 11:03:31 UTC
I never had any problem with e2fsprogs, but since the last update (1.44.5 -> 1.450-r1), i got error emails from my cron system (sys-process/dcron) that looks like:

/bin/sh: root: comando non trovato

It comes from the (new?) file installed by e2fsprogs in /etc/cron.d/e2scrub_all
Comment 1 Hank Leininger 2019-03-24 20:38:04 UTC
Same issue here.

dcron does not support a username field in /etc/cron.d/ files, which other cron daemons do; new e2fsprogs ships+deploys a file not compatible with dcron.

I will attach a patch to the ebuild which:

1) Adds a 'cron' USE flag, defaulting to on (+cron) so the current default behavior does not change.

2) Enforces in RDEPEND that USE=cron is not compatible with sys-process/dcron

3) Tells configure to skip deploying the /etc/cron.d/ file if USE=-cron

That way, current users of dcron can make an informed decision, do I a) switch to a different cron, or b) skip installation of the cron.d file?

Alternately we could patch the to-be-deployed /etc/cron.d/ file to remove the extra field, but that approach may have more subtle hidden surprises (imagine switching from dcron to othercron, and now existing jobs attempt to run as a user named the first field, quite a POLA violation).

Or, Gentoo could mask dcron and require something with the other cron.d format (vixie-cron, anacron, etc.).  But that'd be a much bigger topic, and this can easily be worked around in e2fsprogs for now.
Comment 2 Hank Leininger 2019-03-24 20:39:41 UTC
Created attachment 570676 [details, diff]
Add a +cron USE flag, work around dcron incompatibility
Comment 3 Stefan Schmiedl 2019-05-31 08:01:42 UTC
Yesterday I updated e2fsprogs on some servers running fcron:

# eix sys-fs/e2fsprogs
[I] sys-fs/e2fsprogs
     Available versions:  1.44.5 (~)1.44.6 (~)1.45.1-r1 (~)1.45.2 {cron fuse nls static-libs ELIBC="FreeBSD"}
     Installed versions:  1.45.2(11:11:30 AM 05/30/2019)(nls -cron -fuse -static-libs ELIBC="-FreeBSD")

Tonight I received emails containing

Subject: fcron <systab@s1> test -e /run/systemd/system || //sbin/e2scrub_all -A -r
Body:  WARNING: Failed to connect to lvmetad. Falling back to device scanning.

There is no directory /etc/cron.d on this box, but still the systab contains:

# fcrontab -u systab -l
2019-05-31 09:58:01  INFO listing systab's fcrontab
########################################
# WARNING!!!  DO NOT EDIT THIS FILE!!! #
########################################
# Do not edit this file!  It is automatically generated from
# the /etc/crontab, the /etc/fcron/fcrontab and /etc/cron.d/* files whenever one of
# those files is changed.
#

########################################
# /etc/crontab
########################################
...
########################################
# /etc/cron.d/e2scrub_all
########################################

30 3 * * 0 root test -e /run/systemd/system || /usr/lib64/e2fsprogs/e2scrub_all_cron
10 3 * * * root test -e /run/systemd/system || //sbin/e2scrub_all -A -r

########################################
# /etc/fcron/fcrontab
########################################
...

So the disabled cron USE flag does not seem to prevent e2fsprogs from (how?)
deploying cronjobs to fcron.
Comment 4 Stefan Schmiedl 2019-05-31 08:09:31 UTC
Followup to #3:

I noticed that I did _not_ receive the cron message from the third server I updated yesterday. As far as I can tell, the only relevant difference between the systems is that the non-complaining server does not have lvm2 installed
while the complainers do have it installed (but are not using it).