On 2006-12-21, at 0330, Rick Widmer wrote:

I think I remember you saying that you had your onchange script write to a pipe, and a program running under daemontools c reads the pipe and does the work. If so wouldn't it be a lot faster if vpopmail just wrote to the pipe?

faster, perhaps... but not "a lot faster", and certainly not enough to make up for the additional overhead of having to set up a pipe- listening service, or having to learn how to deal with named pipes to begin with. i see much confusion about setting up and using named pipes, but just about anybody can write a shell script.

for my own needs, the shell script is a stub which writes the command line arguments to the pipe, and then my pipe-listening service does the actual work. this works for me, because the pipe-listening service runs as root, while the pipe itself can be chown()ed, chgrp() ed, and chmod()ed to be writable by non-root processes. yes, i understand that there is the overhead of fork()ing, exec()ing the shell, and parsing and running the script... but i don't think the overhead is as major an issue as you seem to think, unless you're running an ISP with hundreds of thousands of users and several changes (accounts added, deleted, and passwords changed) per second.

I think it would be worthwhile to have --enable-onchange-pipe=/path/ to/pipefile. --enable-onchange-file=/path/to/file should work too. Both should have a reasonable default.

that would involve adding the pipe-writing code to the patch... and for safety the code would also have to verify the existence of the pipe, plus stat() it and make sure that it IS a named pipe (rather than a regular file, directory, symlink, device, or some other kind of filesystem entity) before writing to it...

i think it's easier to just leave it as running a shell script- the concept is a lot easier for people to understand and administer. and again, unless you're running a huge ISP and have a steady stream of changes, the script isn't run so often that the overhead is worth worrying about.

i'm not against the idea (it would make my own server run a wee bit more quickly when accounts are added, for example) but i don't think the issue is critical enough to hold up releasing version 5.4.18. if anybody else is interested in this feature, i'll write a post-5.4.18 patch which adds the functionality, and you can do the ./configure option for it... but don't hold up the 5.4.18 release for this.

| John M. Simpson - KG4ZOW - Programmer At Large |
| http://www.jms1.net/           <[EMAIL PROTECTED]> |
| Mac OS X proves that it's easier to make UNIX  |
| pretty than it is to make Windows secure.      |

Attachment: PGP.sig
Description: This is a digitally signed message part

Reply via email to