Peer Heinlein:
>
> Hi,
>
> we're monitoring the amount of active smtpd processes to make sure, that
> we do not reach the max-proc limit from master.cf.
>
> If a client disconnects very early, the smtpd is still "unused" and
> remains in server memory, waiting for the next connection.

The Postfix behavior has nothing to do with the duration of an SMTP
session. It is determined by the max_idle setting in main.cf.

> If a server was flooded with a short peak of new connections, a server
> could have $process_limit instances remaining ready-to-tun in memory.

You would see the same with a sustained peak of one minute long.
It does not depend on the length of SMTP sessions.

> In that situations we're seeing false positives in our monitoring.

Please fix your monitoring! 

Here is an idea: you could reduce the max_idle setting to 10s.
Systems are a bit faster now than they were 20 years ago.

> I can't see a way how to detect those "waiting" smtpd to cound them
> differently in the process list. AFAIK there's now way (except we're
> counting the number of open connections with lsof/netstat).

Yes, that would be an idea. 

Another idea is to have the master write per-service idle/busy
status to a memory-mapped file.

> What about the idea that Postfix flags those unused processes by
> renaming them in the output of "ps"?

That is very system-dependent. Writing over argv[] is what people
did in 1982, but such code was making assumptions that were never
supported by any promise.

FreeBSD: has setproctitle(), similar to NetBSD and OpenBSD.

    Conclusion: this is a stable API that is safe to use.

Solaris: not supported. Some code tinkers with argv[], but the
    result differs between /usr/bin/ps and /usr/ucb/ps, and the
    change is visible only to root, or to processes that run with
    the same UID as the process that changes its argv[].

    Conclusion: not worth the trouble.

Linux: kludges galore. Some code involves not one, but two approaches:
    modify argv[], and set no more than 16 bytes with prctl(PR_SET_NAME).
    One approach affects ps -a output, the other affects ps -ax
    output. That's because one approach affects /proc/pid/this, and
    the other affects /proc/pid/that.

    Conclusion: prctl(PR_SET_NAME) is safe to use. I would not
    distribute Postfix's own version of the stinking pile of garbage
    that mucks direclty with argv[].

> Dovecot has a "verbose proctitle" option where pop3/imap processes are
> renamed in the process list so that they're showing the logged in user,
> the state of TLS, the client IP and the last IMAP-command.

I would accept an implementation that uses well-defined APIs only:
that is setproctitle() on systems that are known to have it, and
prctl(PR_SET_NAME) on recent enough Linux systems. If a future Linux
version has setproctitle(), then I would use that instead. Until
then you'd have to use the 'right' ps command or read the 'right'
/proc file.

        Wietse

Reply via email to