I just wanted to voice my thoughts on this - I'm not saying I dislike or like any particular solution, but as I've had various thoughts about this over time, I thought it best to just record them.
Putting the logic in the milter init script: pros: It already sources /etc/default/clamav-milter and so already knows if it should be using clamd. Least intrusive fix. Cons: It really has no idea whether clamd is going to start or not - a misconfigured clamav-milter could sleep forever, blocking boot, if clamd has had it's start link removed in rc2.d, for instance. Putting the logic in the clamd init script: pros: We at least know that clamd is supposed to be starting at the point when this script is called. Cons: More intrusive; will have to parse /etc/default/clamav-milter to find out if it should be restarting clamav-milter We don't actually know that clamav-milter is supposed to be running, so restarting it could be the wrong thing (e.g., a disabled install) In general, the logic is also fairly fragile. The clamd init script returns before clamd has set up it's socket for communication, so even doing a restart in one script or another doesn't guarantee that clamav-milter will be able to connect to clamd on startup, and we may end up introducing lots of logic that doesn't do anything useful. I'd like to talk to upstream about having the parent clamd not exit before the child clamd is ready to serve requests, so the init scripts could be synchronous. If they agree to that, then I propose moving the start link for the milter up by 1 and the stop link down by 1, to catch the common bootup/shutdown issues. Finally, at that point I'd like to revisit this and think about how else we could resolve it - ideally, I'd like some logic in the milter itself to sleep and attempt to reconnect so that we don't block boot and get on with things. Upstream may or may not agree to such a change, though. Cheers, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : [EMAIL PROTECTED] | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
signature.asc
Description: Digital signature
