dovecot - Nov 2003 - Pid file?

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20031126/874785ec/attachment-0001.bin>

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.

I'd certainly appreciate the addition of a configurable pid file (either 
  ./configure --with-pid=... or config file). It makes rc.d scripts that 
much neater.

- Robin