[root@bastard-bis ~]# relayctl stop
command failed

Podobnie było z reload. Zanim zaczęło w ogóle działać, relayctl wyświetlał, że opcja jest możliwa. Byłbym szczęśliwy, gdyby stop było reakcją na moje request for feature. Podręcznik systemowy na razie milczy na ten temat.
Dla jasności:

[root@bastard-bis ~]# uname -sr
OpenBSD 4.4

Testy „na szybko” pokazały, że nawet przy wszystkich hostach niedostępnych relayd nie przestaje działać! Daję mu tydzień i wyrzucam LVS + Keepalived :-)

Aug  1 01:31:10 bastard-bis relayd[14496]: host 10.0.25.249, check send expect (0ms), state up -> down, availability 98.33%
Aug  1 01:31:10 bastard-bis relayd[14496]: host 10.0.25.249, check tcp use ssl (1ms), state up -> down, availability 98.33%
Aug  1 01:31:15 bastard-bis relayd[14496]: host 10.0.25.247, check send expect (210ms), state up -> down, availability 91.80%
Aug  1 01:31:15 bastard-bis relayd[14496]: host 10.0.25.247, check tcp use ssl (211ms), state up -> down, availability 88.52%
Aug  1 01:31:30 bastard-bis relayd[14496]: host 10.0.25.249, check send expect (54ms), state down -> up, availability 93.75%
Aug  1 01:31:30 bastard-bis relayd[14496]: host 10.0.25.249, check tcp use ssl (61ms), state down -> up, availability 93.75%
Aug  1 01:31:45 bastard-bis relayd[14496]: host 10.0.25.247, check send expect (1ms), state down -> up, availability 85.07%
Aug  1 01:31:45 bastard-bis relayd[14496]: host 10.0.25.247, check tcp use ssl (52ms), state down -> up, availability 82.09%

Obecnie działa całkiem dobrze, ale ma pewne niedociągnięcia. Przykładowo proces rodzic nie zapisuje swojego PIDa w /var/run. Ot niby drobnostka, ale jednak. relayctl (8) mógłby też obsługiwać komendę shutdown. Wysłałem nawet w tej sprawie feature request i oto co otrzymałem w odpowiedzi od Pierre-Yves Ritschard:

My answer:

$ sudo -i
# pkill relayd.
# relayd

ekipa Theo…

Żeby było bardziej technicznie, to sekcja REDIRECTIONS wygląda u mnie tak:

redirect smtpredirect {
listen on $ext_addr port smtp
listen on $ext_addr port submission
forward to <mailhosts> check send nothing expect „220 *”
}

redirect smtpsredirect {
listen on $ext_addr port smtps
forward to <mailhosts> check ssl
}

Nie wiem czemu, ale przez SMTPS nie zadziałało pobieranie odpowiedzi, więc jest tylko nawiązywane połączenie SSL (SSL handshake).

Poza tym przy dwóch przekierowaniach demon często przestaje działać (chyba dlatego). W logach można zobaczyć coś takiego (data i godzina jakoś tak zabawnie się zgrały :>):

[...]
Jul  3 13:37:13 bastard relayd[6348]: host 10.0.25.249, check tcp use ssl (210ms), state up -> down, availability 94.53%
Jul  3 13:37:13 bastard relayd[6348]: host 10.0.25.247, check tcp use ssl (210ms), state up -> down, availability 93.01%
Jul  3 13:37:16 bastard relayd[19372]: fatal: flush_table: cannot flush table stats: Operation not supported by device
Jul  3 13:37:16 bastard relayd[6348]: host check engine exiting
Jul  3 13:37:16 bastard relayd[17749]: check_child: lost child: pf update engine exited
Jul  3 13:37:16 bastard relayd[17749]: terminating

A na serwerze pocztowym (przesunięcie czasowe jednych logów względem drugim nie ma znaczenia):

Jul 15 00:03:40 mailin-ng2 postfix/smtpd[4609]: setting up TLS connection from bastard[10.0.25.254]
Jul 15 00:03:40 mailin-ng2 postfix/smtpd[4609]: Anonymous TLS connection established from bastard[10.0.25.254]: TLSv1 with cipher DHE-RSA-AES25
6-SHA (256/256 bits)
Jul 15 00:03:40 mailin-ng2 postfix/smtpd[4609]: lost connection after CONNECT from bastard[10.0.25.254]
Jul 15 00:03:40 mailin-ng2 postfix/smtpd[4609]: disconnect from bastard[10.0.25.254]
[...]
Jul 15 00:03:45 mailin-ng2 postfix/smtpd[4609]: connect from bastard[10.0.25.254]
Jul 15 00:03:45 mailin-ng2 postfix/smtpd[4609]: setting up TLS connection from bastard[10.0.25.254]
Jul 15 00:03:45 mailin-ng2 postfix/smtpd[4609]: SSL_accept error from bastard[10.0.25.254]: -1
Jul 15 00:03:45 mailin-ng2 postfix/smtpd[4609]: lost connection after CONNECT from bastard[10.0.25.254]
Jul 15 00:03:45 mailin-ng2 postfix/smtpd[4609]: disconnect from bastard[10.0.25.254]

Być może jest to związane z faktem, że jednocześnie wszystkie hosty są niedostępne. Podobno od maja w -current jest to poprawione (jakiś tydzień po 4.3).

Working file: relayd.c
revision 1.74
date: 2008/05/06 09:52:47; author: pyr; state: Exp; lines: +10 -1
do not attempt to reload a configuration if we come from a non pf
requiring configuration to a pf requiring one.
ok reyk@

Working file: relayd.h
revision 1.100
date: 2008/05/06 06:09:48; author: pyr; state: Exp; lines: +2 -1
Do not unconditionnaly load pf. If pf isn’t required by the configuration
the initialisation isn’t done properly.

Working file: pfe_filter.c
revision 1.25
date: 2008/05/06 11:52:49; author: reyk; state: Exp; lines: +6 -1
fix the table stats clr ioctl

Working file: relay.c
revision 1.88
date: 2008/05/05 12:33:55; author: pyr; state: Exp; lines: +4 -1
Put relay sockets in non blocking mode too. This got forgotten along the
way and didn’t show since our read buffers are small.
„put it in” reyk@

No cóż, pozostaje czekać do listopada…

… a tymczasem:

pfctl -a ‘relayd/smtpredirect’ -Fa