Is there a way to make Dovecot maintain a pid file? Most daemons put their pid in /var/run/dovecot.pid (or similar) while they are running, then remove it on exit, but I can't find any option to do this in Dovecot.
(Of course, if I could work out how on earth to stop Dovecot leaking processes, I wouldn't be looking for a simpler way to keep bringing the daemon down and restarting it. (-8 )
Regards,
--Clive.
On Wed, 2003-11-26 at 13:04, Clive Jones wrote:
Is there a way to make Dovecot maintain a pid file? Most daemons put their pid in /var/run/dovecot.pid (or similar) while they are running, then remove it on exit, but I can't find any option to do this in Dovecot.
Hmm. I guess I could add it.
(Of course, if I could work out how on earth to stop Dovecot leaking processes, I wouldn't be looking for a simpler way to keep bringing the daemon down and restarting it. (-8 )
Well, I thought you would have looked at 0.99.10.4 release announcement mail:
- Fixed reference counters in imap-login and pop3-login.
IMAP AUTHENTICATE and POP3 AUTH commands could have left the
process stuck doing nothing forever.I'd think it fixes your problem.
Also last night I started thinking about this problem in general and figured out that manual reference counting is a bad idea. Either you unref too much and cause double-free() security holes, or you forget to unref something and it can be used to DoS like in this case.
Garbage collector would help .. but I don't really like the idea of depending on Boehm GC. It's bloaty and I haven't had very good experiences with it so far. I couldn't figure out why it's incorrectly freeing some part of memory when running THREAD command and causing crashes.
So.. I haven't fully finished my plan, but I think it would work if I made some kind of GC for "objects". There would be just a few of them, mostly where I use refcounting now. It would be fully ANSI-C and it might not be as easy to use as real GC, but I think I could make it safe so these kind of security holes would be prevented.
Timo wrote:
Well, I thought you would have looked at 0.99.10.4 release announcement mail:
Ah, oops. I figured I wasn't going to bother with any upgrades until the bug was fixed, and forgot you might only mention the bug fix in the release notes. Sorry!
I've now built the new version, and will try deploying this evening.
Incidentally, building a new version of dovecot has reminded me of a problem I encountered building under OpenBSD (version 3.2). When using dlsym() to find C symbols in shared objects, the symbol name must be prefixed with an underscore. For the time being, I've fixed the issue with the following shim in src/auth/auth-module.c : 97a98
char buf[64];
101c102,106 < ret = dlsym(module->handle, name);
buf[0]='_'; strncpy(buf+1,name,62); buf[63]='\0'; ret = dlsym(module->handle, buf);
Without that fix, using modules for auth_userdb or auth_passdb won't work.
I'm sure there must be some elegant way to deal with this portability issue, but for the moment it eludes me. (-8
Regards,
--Clive.
participants (2)
-
Clive Jones
-
Timo Sirainen