(someone replied to me in private, but I thought the explanation might be useful to the wider audience ... so, to that user, I'm sorry for technically violating netiquette by sending this on, but it's being done for a good reason, I think ... if you don't agree,I'm sorry, and if you say so, I wont do this again)
> >option? We get enough pop processes on our server that having config > >files creates a resource contention problem on the disk where the config > >file lives, so config files == bad. > > [snip] > > > >Ideally, every config file option would have a CLI equivalent. > > There are provisions for having every user using a separate configuration > file. But really I have to ask... what is wrong with using a config file > instead of command line switches? > I trimmed my part of the above down because the answer to your question was in my message. To explain it a little more, if a popper starts up and then immediately tries to open a config file, it's going to hang while waiting for IO. If you've got 15000 users, that can build up. For example, in the last two days, when I forgot about this issue, I accidently enabled config files for the poppers, and I had, at some points, 6000 popper processes all sleeping on waiting to open their config files. (limiting the number of processes only trades symptoms of "painfully slow pop processes that ultimately timeout" for "refusing connections" ... either way it's a problem, and neither one happens if you aren't using config files ... and in that case, the turn over is usually fast enough that the number of pop processes doesn't tend to grow past 1000 any way) Part of it is "where does the config file live"? The default location is in /etc/mail/pop ... on the root disk, along with the sendmail config file, things like the nsswitch.conf, hosts.allow and hosts.deny, etc. Oh, and the password file. Things that get used A LOT. To a certain extent, the problem can be solved by putting lots of things on different disks ... but in the most extreme case, that starts to look like a disk for just /etc/mail/pop. That doesn't scale much better than having everything in /etc. In contrast, if the config files don't exist, the IO process is much faster, and the poppers barely hang. But, in order for that to happen, you have to be able to specify everything on the command line (or in the configure script, but that can be a little too static for my tastes, I don't want to have to recompile just to change every little decision). As for user specific config files ... users don't directly use this machine. It's a pop server only (it even only runs smtp for receiving messages from our SMTP servers ... and the hosts.allow / hosts.deny keep other machines using it as an SMTP server). So, that would mean I'd have to maintain ~15k config files in order to have central config options for everyone? That doesn't scale very well. I'ts not an immediate concern because SPOP is the only thing I've got that _requires_ a config file, and SPOP isn't a production service yet (it would be if eudora worked with stunnel, but eudora is the ONE pop client that supports ssl and yet wont work with a non-ssl popper sitting behind stunnel ... and unfortunately, eudora is our one officially supported mail client). Our kpop, pop3, and pop2 daemons don't need one. But, considering what happens to performance if I add a config file for those daemons, I'm not going to make SPOP a production service until I can specify everything it needs upon the command line.
