Dear Bill,
Thanks very much for helping.
> On Aug 19, 2016, at 4:17 AM, Bill Cole
> <postfixlists-070...@billmail.scconsult.com> wrote:
>
>> What do you mean "run" the policy service? It's a python program.
>
> Which must be running in order for it to be listening for connections.
> Likely mechanisms would be via a SysV init script in /etc/init.d/ or via a
> systemd service definition.
On some old Linux distributions, it's run with a SysV init script, but on
CentOS 7 and Ubuntu 16.04, it's run via systemd.
> If your policy server is listening on 127.0.0.1:1234, you could try this:
>
> for x in {1..100} ; do nc 127.0.0.1 1234 & done
>
> That attempts to make 100 TCP connections to 127.0.0.1:1234 with 100
> different 'nc' processes, all running in the background.
>
> If your policy server is accepting the connections, running the "jobs"
> command after all of those background processes have launched should show
> them all in "Stopped(SIGTTIN)" state, meaning that they are connected and
> waiting for input.
I did this test with shell:
for i in $(seq 200); do
nc 127.0.0.1 1234 &
done
'jobs' commands show 200 "Stopped" jobs.
> If all 100 processes connect in a reasonable time, the next step would be to
> do the same test, but with input piped into all of the nc commands simulating
> what Postfix sends to a policy server.
I tested with shell commands below:
for i in $(seq 1000); do
(cat <<EOF
request=smtpd_access_policy
protocol_state=RCPT
... [omit other attr=value here] ...
ccert_pubkey_fingerprint=
EOF
) | nc 127.0.0.1 7777 &
done
I get some "Ncat: Connection reset by peer." and "Ncat: Connection timed out."
errors.
Does it mean that my policy server design (programming) is improper? Or, just
slow performance?
