When spamd gets reinstalled (including by upgrade), the /etc/services entries are deleted during deinstall but not recreated during reinstall. As a result, spamd won't start after an upgrade. It looks like it is happening because the pkg-* scripts are not run in the order than spamd is anticipating. [root@lockup ~] poudriere bulk -j 10amd64 -i mail/spamd [...] root@lockup:~ # grep spamd /etc/services spamd 8025/tcp # spamd(8) spamd-sync 8025/udp # spamd(8) synchronisation spamd-cfg 8026/tcp # spamd(8) configuration root@lockup:~ # pkg upgrade -f spamd [...] [lockup] [1/1] Reinstalling spamd-4.9.1_3... ===> Creating groups. Using existing group '_spamd'. ===> Creating users Using existing user '_spamd'. Checking /etc/services for missing service entries <-- pkg-install [lockup] [1/1] Extracting spamd-4.9.1_3: 100% ===> Removing spamd entries from /etc/services <-- pkg-deinstall [...] root@lockup:~ # grep spamd /etc/services root@lockup:~ # It looks as if pkg-deinstall is being run after the pkg-install, which seems strange... I would have thought that the deinstall should run before the install. I'm not sure whether this is a problem with spamd or with pkg, so I'm Cc'ing portmgr for input.
Hi Adam, I'm not sure but I suspect this a a bug in pkg. $ script -q $log pkg -o DEBUG_LEVEL=4 upgrade -f spamd $ grep ^set $log set -- spamd-4.9.1_3 set -- spamd-4.9.1_3 PRE-INSTALL set -- spamd-4.9.1_3 DEINSTALL set -- spamd-4.9.1_3 POST-INSTALL Inspection the log it seems the order during reinstall is wrong. In that case it would affect more users if ports using a PRE-INSTALL section and trying to cleanup them self. Sadly I have no system with an older pkg at the moment for tests since I haven't noticed this before.
Can someone from pkg@ weigh in here? Olli: is it worth disabling the pkg-deinstall for now?
Olli, pkg@ has a huge bug backlog (currently 50 here and over 200 on github). I'd recommend that spamd disable its pkg-deinstall until the bug in pkg gets fixed. It eliminates the behaviour of spamd breaking on upgrade/reinstall, and the only negative side effect is that the entries for spamd remain in /etc/services if spamd is uninstalled.
The order is actually expected. I should probably document somewhere the why and the how an upgrade is process. But this is totally not a first deinstall then install as it does not work at all on complex cases. the backlog, on pkg is mostly feature request or thing we keep open because we do not necessary agree in the beginning with the request that have been made, but we might change our mind in the feature :)
So then what's the right way for spamd to handle adding and removing lines from /etc/services? If it adds the lines in POST-INSTALL would that always run after DEINSTALL?
The right way is to add things in post-install: aka only if the installation has succeed which is anyway better Actually the best would be to add a keyword for that :) so all ports adding services would benefit from it :)
I would propose this: https://reviews.freebsd.org/D8504
Olli, this problem still exists and causes problems every time spamd is reinstalled (system upgrades, in particular, where spamd fails so the firewall fails to start). Can you please give approval to disable pkg-deinstall? This problem needs to be mitigated at least temporarily.
Olli, it's been almost a year since you commented on this bug. Unless you register an objection before then, I'm going to disable the pkg-deinstall on Saturday.
A commit references this bug: Author: adamw Date: Fri Sep 1 22:03:05 UTC 2017 New revision: 449108 URL: https://svnweb.freebsd.org/changeset/ports/449108 Log: Disable the pkg-deinstall script. spamd's pkg-install adds spamd stuff to /etc/services, and pkg-deinstall removed it. The problem is that pkg doesn't run DEINSTALL before INSTALL when upgrading/reinstalling. As a result, when spamd is restarted, /etc/services winds up lacking the spamd entries, causing spamd to fail to start. The ideal solution is pkg running those targets in the predicted order, or pkg gaining a @services keyword. In the meantime, this commit just disables the pkg-deinstall. If you are uninstalling spamd you can remove those /etc/services entries by hand. PR: 212335 Approved by: maintainer timeout (~ 1 yr) MFH: 2017Q3 Changes: head/mail/spamd/Makefile head/mail/spamd/pkg-deinstall
A commit references this bug: Author: adamw Date: Sat Sep 2 15:03:53 UTC 2017 New revision: 449149 URL: https://svnweb.freebsd.org/changeset/ports/449149 Log: MFH: r449108 Disable the pkg-deinstall script. spamd's pkg-install adds spamd stuff to /etc/services, and pkg-deinstall removed it. The problem is that pkg doesn't run DEINSTALL before INSTALL when upgrading/reinstalling. As a result, when spamd is restarted, /etc/services winds up lacking the spamd entries, causing spamd to fail to start. The ideal solution is pkg running those targets in the predicted order, or pkg gaining a @services keyword. In the meantime, this commit just disables the pkg-deinstall. If you are uninstalling spamd you can remove those /etc/services entries by hand. PR: 212335 Approved by: maintainer timeout (~ 1 yr) Approved by: ports-secteam (delphij) Changes: _U branches/2017Q3/ branches/2017Q3/mail/spamd/Makefile branches/2017Q3/mail/spamd/pkg-deinstall
Closing this. I don't think a pkg behaviour change in this area is coming, and it works well-enough with the current patch.