well this is what i have after upgrading tp 3.0.0
ps -ef|grep spamd
root 23320 27167 0 11:58:56 ? 0:17 /usr/local/bin/perl -T /usr/local/bin/spamd -d -r /logs/spamd.pid
root 27167 1 0 Oct 15 ? 0:02 /usr/local/bin/perl -T /usr/local/bin/spamd -d -r /logs/spamd.pid
root 18777 27167 3 09:57:25 ? 1:14 /usr/local/bin/perl -T /usr/local/bin/spamd -d -r /logs/spamd.pid
root 19749 27167 8 10:13:03 ? 1:26 /usr/local/bin/perl -T /usr/local/bin/spamd -d -r /logs/spamd.pid
root 19250 27167 0 10:01:50 ? 1:03 /usr/local/bin/perl -T /usr/local/bin/spamd -d -r /logs/spamd.pid
root 21501 27167 0 10:55:07 ? 0:30 /usr/local/bin/perl -T /usr/local/bin/spamd -d -r /logs/spamd.pid
If it finds itself running as still running as root after that, it will setuid to "nobody" when it starts to scan mail.
but before when i was running 2.6.x(3) i think! spamd(root) did what youve said and called the others as user 'nobody'
Were any of those spamd's scanning mail at the time?
SA 3.0 pre-forks children, which SA 2.6 did not. Thus, when SA 2.6 forked, they were already handling a connection and suided to nobody.
In SA 3.0, the children will pre-fork, idle as root, then it should setuid to nobody when a spamc connects.
They will then bail back out of that setuid when they are done scanning, so you will generally see them running as root, but only when they are idle.
Disclaimer: I've not tested this, but it is the theory of operation that SA 3.0 was designed to, and what you show me above does not disprove that theory.
If you want to specify a single user to run spamd as, use the -u parameter to spamd.both were acalled using the same commandline
/usr/local/bin/spamd -d -r /logs/spamd.pid
Yep, thus both are relying on the default fall-back behavior, but see above.. SA 3.0 forks much differently than 2.6 does.
