Re: refusing connections based on load ...
От | Larry Rosenman |
---|---|
Тема | Re: refusing connections based on load ... |
Дата | |
Msg-id | 20010423215056.A763@lerami.lerctr.org обсуждение исходный текст |
Ответ на | Re: refusing connections based on load ... (Larry Rosenman <ler@lerctr.org>) |
Список | pgsql-hackers |
* Larry Rosenman <ler@lerctr.org> [010423 21:45]: > * The Hermit Hacker <scrappy@hub.org> [010423 21:38]: > > On Mon, 23 Apr 2001, Tom Lane wrote: > > > > > The Hermit Hacker <scrappy@hub.org> writes: > > > > sendmail does it now, and, apparently relatively portable across OSs ... > > > > > > sendmail expects to be root. It's unlikely (and very undesirable) that > > > postgres will be installed with adequate privileges to read /dev/kmem, > > > which is what it'd take to run the sendmail loadaverage code on most > > > platforms... > > > > Actually, not totally accurate ... sendmail has a 'RunAs' option for those > > that don't wish to have it run as root, and still works for the loadavg > > stuff, to the best of my knowledge (its an option I haven't played with > > yet) ... > And 8.12.x will have some other options as well.... > > Like the SUBMISSION prog only needs to be SGID, not SUID.... Actually, the sendmail DAEMON will still have ROOT privs, so it can read /dev/kmem. I suspect I don't have as much of an issue if we are sgid kmem... LER > > LER > > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 972-414-9812 E-Mail: ler@lerctr.org > US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
В списке pgsql-hackers по дате отправления: