Hello, I asked here once ago, but got no replies.
If you have a previously overloaded system that built up a large queue, disabling fsync() is like an overboost switch: Not for regular operation, but it solves the problem and brings you back to regular operation, allowing to care about the original problem. Apart from that, I run a spam honeypot where losing mail is no problem. Avoiding fsync() for regular operation allows to run it on a way cheaper system. A command line option does not help, because it would not be passed to queue runners and their children. Either you compile Exim without fsync() or introduce a new configuration file option. Having an extra executable finally annoys me enough to bring this topic up again. Philip does not like an option like that, because dumb admins may use it without being aware of the risks. That's a valid point. Me, I think the flexibility of Exim allows to screw up so many things already, that dumb admins probably screw up already and have nothing to lose. I wouldn't mind if the daemon logged a message about unsafe operation to mainlog when starting up. I am trying to reduce the amount of private Exim patches and getting this in the main distribution helps me a lot, plus it may help others that know what they are doing. Remember ghost busters: There will be the day when you have to cross the streams. ;-) Any comments are appreciated! Michael -- ## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
