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