Bug#520558: please re-open or reconsider
Paul Traina schrieb am Freitag, den 02. Oktober 2009: So upon doing some more research and work, and testing on MY system, this is, I believe, the correct answer for most installations, and should not cause any problems for any installations: I still disagree that this should defined by us. I have amavis installations that need: postgresql, mysql, memcached, collectd and so on. Its not our job to define every possibility. But if you and Henrique reach consense I will upgrade the initscript. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520558: please re-open or reconsider
Paul Traina schrieb am Sonntag, den 04. Oktober 2009: It's perfectly reasonable to put ALL of them under the should section if amavis needs them running first. There is no all. Since its perl and its customizable you can't know every service it uses or is able to use. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520558: please re-open or reconsider
It's perfectly reasonable to put ALL of them under the should section if amavis needs them running first. On Oct 4, 2009, at 3:28 AM, Alexander Wirt formo...@debian.org wrote: Paul Traina schrieb am Freitag, den 02. Oktober 2009: So upon doing some more research and work, and testing on MY system, this is, I believe, the correct answer for most installations, and should not cause any problems for any installations: I still disagree that this should defined by us. I have amavis installations that need: postgresql, mysql, memcached, collectd and so on. Its not our job to define every possibility. But if you and Henrique reach consense I will upgrade the initscript. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520558: please re-open or reconsider
On Fri, 02 Oct 2009, Paul Traina wrote: So upon doing some more research and work, and testing on MY system, this is, I believe, the correct answer for most installations, and should not cause any problems for any installations: ### BEGIN INIT INFO # Provides: amavisd-new # Required-Start:$syslog $network $local_fs $network $named $time # Required-Stop: $syslog $network $local_fs $network # Should-Start: postgresql mysql ldap clamav-daemon # Should-Stop: postgresql mysql ldap clamav-daemon # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Starts amavisd-new mailfilter # Description: Launches the amavisd-new mailfilter ### END INIT INFO The only question is, should local_fs be, more conservatively, remote_fs? You can use remote_fs, yes. Or even both (but first, please look at the docs to see if remote_fs implies local_fs. I think it does). Any proper setup of amavisd-new can deal with it starting late. The should stuff will be counted only if there are packages that provide the servers in question. Do we need clamav-daemon in there? I don't object to the other deps, but clamav-daemon really shouldn't need to be started before amavisd-new... As you can see, this will start amavisd-new either at the same time, or before the MTA. I think that's more proper than my earlier solution of starting it after the MTA, as there is a tiny window where the MTA could attempt to receive mail and amavis isn't ready. I wouldn't approve a patch where amavisd-new gets forced to start after the MTA at all :) Please consider incorporating this patch into the next update. We will. But let's get it perfect and tested first, since it should not take much more effort to be assured that we will get it right on the first upload. Again, it shouldn't break things that don't have any of the should severs (or do). Did you test it? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520558: please re-open or reconsider
I did look at the docs before sending in the fragment. In no place in the LSB documentation does remote_fs imply that local_fs has already happened, so technically, having both is a good thing. Many scripts have both. /usr can technically be remote_fs. I was trying to change as little as possible with my submitted fragment, but I suspect the more conservative remote_fs and local_fs is the right answer. Do we need clamav-daemon in there? I don't object to the other deps, but clamav-daemon really shouldn't need to be started before amavisd- new... Again, it's a windowing problem. Amavisd-new technically doesn't need to be started before the MTA, but the services should be in place. If clamav-daemon isn't around, we may or may not fall back to clamscan, but amavis is looking to connect to the control socket for clamav- daemon, so I think it's perfectly reasonable to put it in the should, along with they SQL databases. It's principle of least astonishment. please just work right Again, it shouldn't break things that don't have any of the should severs (or do). Did you test it? Extensively, under my environment, which is postfix+amavis+clamav +spamassassin but not using LDAP or MYSQL for amavis-purposes (but having MYSQL on the machine for other reasons and no LDAP at all). This should give us reasonable coverage. The only change I can see is adding the more conservative $remote_fs. It's actually amazing how many scripts in /etc/init.d/rc are still somewhat broken, networking stuff like apache not waiting for $named and $time. Obvious bugs... but we'll at least get our stuff right. The easy way to test it is to make changes, then just run insserv and you can see (sanity check) where the file actually shows up in /etc/ rc2.d ... and then reboot at will. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520558: please re-open or reconsider
On Sat, 03 Oct 2009, Paul Traina wrote: I did look at the docs before sending in the fragment. In no place in the LSB documentation does remote_fs imply that local_fs has already happened, so technically, having both is a good thing. Many So, we list both. Do we need clamav-daemon in there? I don't object to the other deps, but clamav-daemon really shouldn't need to be started before amavisd- new... Again, it's a windowing problem. Amavisd-new technically doesn't need to be started before the MTA, but the services should be in place. If clamav-daemon isn't around, we may or may not fall back to clamscan, but amavis is looking to connect to the control socket No fallback to clamscan is considered an unsupported configuration, but I have no strong feelings about this dependency. Again, it shouldn't break things that don't have any of the should severs (or do). Did you test it? Extensively, under my environment, which is postfix+amavis+clamav +spamassassin but not using LDAP or MYSQL for amavis-purposes (but having MYSQL on the machine for other reasons and no LDAP at all). This should give us reasonable coverage. Yes. One last corner case: please add a dependency to a service amavisd-new does _NOT_ need to work, and make that service *fail* to start (with a non-zero status code). amavisd-new must still attempt to start. Does that happen? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520558: please re-open or reconsider
Unfortunately, the new dependency based stuff (depricating sysv-rc) breaks amavis. Yes, amavis can depend upon a lot of stuff needing to start, so it SHOULD start after those things, if they exist and are installed. The LSB stuff in /etc/init.d/amavisd-new should be tweaked or auto- generated to fix this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520558: please re-open or reconsider
On Fri, 02 Oct 2009, Paul Traina wrote: Yes, amavis can depend upon a lot of stuff needing to start, so it SHOULD start after those things, if they exist and are installed. The LSB stuff in /etc/init.d/amavisd-new should be tweaked or auto- generated to fix this. The only way we could autogenerate would be to have something the local admin can run, which will suggest changes to the LSB headers. That's way too much complexity for very, very little gain IMO. Anyway, the initscript is a conffile for a reason. The local admin is expected to edit it when necessary (and re-run insserv to reorder the boot, etc). And since the package is NOT going to use LDAP or SQL by default anyway, it can easily be argued that just documenting the need to edit the initscript (and give examples to make it easier, etc) would be enough. The alternative, which can be used only if the dep-based support is smart enough to let us depend conditionaly on, e.g., ldap and sql (as in: if any initscript provinding that exists, start after them) without causing trouble, would be to list by default the saner dependencies (LDAP, SQL). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520558: please re-open or reconsider
So upon doing some more research and work, and testing on MY system, this is, I believe, the correct answer for most installations, and should not cause any problems for any installations: ### BEGIN INIT INFO # Provides: amavisd-new # Required-Start:$syslog $network $local_fs $network $named $time # Required-Stop: $syslog $network $local_fs $network # Should-Start: postgresql mysql ldap clamav-daemon # Should-Stop: postgresql mysql ldap clamav-daemon # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Starts amavisd-new mailfilter # Description: Launches the amavisd-new mailfilter ### END INIT INFO The only question is, should local_fs be, more conservatively, remote_fs? The should stuff will be counted only if there are packages that provide the servers in question. As you can see, this will start amavisd-new either at the same time, or before the MTA. I think that's more proper than my earlier solution of starting it after the MTA, as there is a tiny window where the MTA could attempt to receive mail and amavis isn't ready. Please consider incorporating this patch into the next update. Again, it shouldn't break things that don't have any of the should severs (or do). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
