pkg_config() in the current munin ebuild tries to enter an crontab entry in this way: crontab -u munin /var/lib/munin/crontab this is correct for the vixie-cron crontab(1)and maybe others, but dcron uses a slightly different syntax. The correct way to do it with dcron is: crontab /var/lib/munin/crontab -u munin You could say it's got it backwards, therefore emerge --config net-analyzer/munin results in the crontab(1) help output and no crontab installed when dcron is installed. Not sure if there's already an eclass/function dealing with user cron entries (cron.eclass doesn't) but extending one would probably be the intelligent fix. Quicker: drop the automatic installation and simply print instructions on how to add the crontab for different cron implementations. Reproducible: Always Steps to Reproduce: 1. emerge sys-process/dcron 2. emerge net-analyzer/munin 3. emerge --config net-analyzer/munin Actual Results: crontab V3.2 crontab file <opts> replace crontab from file crontab - <opts> replace crontab from stdin crontab -u user specify user crontab -l [user] list crontab for user crontab -e [user] edit crontab for user crontab -d [user] delete crontab for user crontab -c dir specify crontab directory Expected Results: crontab should be installed for user munin, or warning given by pkg_config how to add it manually.
Can I do this safely on dcron? crontab -u munin </var/lib/munin/crontab
(In reply to comment #1) > Can I do this safely on dcron? > crontab -u munin </var/lib/munin/crontab > No, but you can do one of those two: # crontab /var/lib/munin/crontab -u munin # crontab - -u munin </var/lib/munin/crontab I have tried other combinations, which don't work: # crontab -u munin </var/lib/munin/crontab # crontab -u munin - </var/lib/munin/crontab # crontab -u munin /var/lib/munin/crontab Also, it only works as root: $ crontab - -u munin </var/lib/munin/crontab crontab: only the superuser may specify a user HTH.
> # crontab - -u munin </var/lib/munin/crontab That one works on vixie-cron too (the file-specific on does not). Fixed in 1.3.4 now.
