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
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.
Created attachment 570676 [details, diff] Add a +cron USE flag, work around dcron incompatibility
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.
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).
I can confirm the bug is still present as of now.
I think this issue is still present for dcron users, but no longer tripped over by default. The bundled e2scrub_all still has assumptions about the cron implementation's behavior that don't work with dcron (they contain a username column). However, now that cron is a USE flag and not on by default, the issue won't come up for most dcron users. I'd still recommend we add either an RDEPEND of 'cron? ( !sys-process/dcron )', or sanitize the e2scrub_all file. The latter runs a risk of introducing an incompatibility if later on cron is switched to something else that _does_ support (and require) the username column. To handle that I like how sysstat handled it: IUSE="dcron ..." RDEPEND=" ... !dcron? ( !sys-process/dcron ) src_prepare() { if use dcron; then sed -i 's/@CRON_OWNER@ //g' cron/sysstat.crond.in || die fi Something like that, maybe in this case gated by cron? !dcron? , so that: - if no cron support enabled, nothing happens - if cron support enabled, and USE=dcron not enabled, then refuse to coexist with dcron installed - if cron support enabled, and dcron enabled, fixup for dcron compatibility
