Description of problem: urpme mailman did not remove /etc/cron.d/mailman journalctl | grep failed Jan 18 06:50:01 tb.home.test crond[2110]: (/usr/bin/python) ERROR (getpwnam() failed) # grep -r python /etc/cron.* /etc/cron.d/mailman:0 8 * * * /usr/bin/python -S /usr/lib64/mailman/cron/checkdbs Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. if no /etc/cron.d/mailman 1. install mailman 2. urpme mailman 3. ls /etc/cron.d/mailman Workaround: rm /etc/cron.d/mailman Reproducible: Steps to Reproduce:
*** Bug 17652 has been marked as a duplicate of this bug. ***
Where did the /etc/cron.d/mailman file come from? It's not apparent that it came from the package. I do see that the package installs a crontab for the mailman user (/var/spool/cron/mailman), which it does remove when being uninstalled. Did you create /etc/cron.d/mailman yourself?
(In reply to David Walser from comment #2) > Where did the /etc/cron.d/mailman file come from? It's not apparent that it > came from the package. I do see that the package installs a crontab for the > mailman user (/var/spool/cron/mailman), which it does remove when being > uninstalled. Did you create /etc/cron.d/mailman yourself? Nope. I did a Clean network install of Cauldron 6-x86_64 enabled non-free and tainted Picked Custom package install In Package Group Selection screen set all package groups selected except Other Graphical Desktops. In that one select Gnome and KDE. Part of my new_install script does a urpme mailman.
assinging to all packagers collectively, since there is no maintainer for mailman
CC: (none) => marja11Assignee: bugsquad => pkg-bugs
Summary: mga6: urpme mailman did not remove /etc/cron.d/mailman => 6_s1: urpme mailman did not remove /etc/cron.d/mailman
Nothing in /etc/cron.d
Status: NEW => RESOLVEDResolution: (none) => FIXED
It looks like /etc/cron.d/mailman is created/maintained by the mailman service. It is emptied but not removed when mailman is uninstalled. /var/lib/mailman and /var/log/mailman are also left behind when mailman is uninstalled. I know that config files are commonly left as rpmsave files but I don't know what is customary for application data. /var/lib/mailman has all the mailman mail lists and archive data. I've still got some changes pending for the post installation scriptlet error that is seen under certain circumstances. I could add the removal of these items to those changes if it is appropriate. Thoughts?
CC: (none) => mrambo
(In reply to Mike Rambo from comment #6) > It looks like /etc/cron.d/mailman is created/maintained by the mailman > service. Well, that explains why I did not see it during my sta2 open problem testing. Service failed to created it for whatever reason. > It is emptied but not removed when mailman is uninstalled. Yup, it took me a few days to track down where it was. All I saw was cron failure messages. I modified my sys_audit script to warn me about anything in /etc/cron.d > /var/lib/mailman and /var/log/mailman are also left behind when mailman is > uninstalled. I know that config files are commonly left as rpmsave files but > I don't know what is customary for application data. /var/lib/mailman has > all the mailman mail lists and archive data. I've still got some changes > pending for the post installation scriptlet error that is seen under certain > circumstances. I could add the removal of these items to those changes if it > is appropriate. Thoughts? In my opinion, if I remove a package, I want everything installed/generated to be removed. It helps with automatic initial and regression application testing. In general, if the database becomes corrupt or has invalid data I would have thought a urpme/urpmi would get me back to a day one condition so I would have a much better chance of finding out what introduces the problem or get the application back online. Any smart sys admin would have a script to reload data from ASCII file(s) whenever possible. Relying on just database backup is asking for trouble.