Re: RFV: pass-through persist and daemon re-configuration with HUP

--===============1836076483==
Content-Type: multipart/alternative;
boundary="----=_Part_28262_5234422.1161858293607"

------=_Part_28262_5234422.1161858293607
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Sorry to have caused the argument ;) And despite having proposed it, I am
not actually sure that I am still in favour of the patch.

The problem can (and indeed should) be fixed in the pass_persist script.
Using select, the call will return with the fd set and the subsequent read
will result in EOF (another read will result in EPIPE error). Using poll,
the call will return with POLLHUP set meaning that the fd has been
closed/disconnected and the subsequent read will also result in EOF. The
pass_persist script should handle this case and shutdown cleanly. I think
this is part of the protocol and should be added to the documentation in the
snmpd.conf man page. It should also be ensured that the fd is not closed
prematurely for any other reason. If a persistent script is used to avoid
repeating a lengthy setup procedure (which I suppose is one fairly typical
reason), this would defeat the purpose.

The remaining question is whether the daemon wants to protect itself from an
erroneous script and in particular the blocking waitpid call. I agree that
any script should behave correctly (and according to the protocol) and that
there are numerous ways that an erroneous script could block/harm the
daemon. You cannot cover all the cases, but I still think that the daemon
should protect itself from this particular case as the blocking waitpid call
is potentially dangerous. The pass-through script should be given a chance
to shutdown cleanly but if it doesn't take that chance (in a reasonable
amount of time), then it should be forcefully shutdown. But as already
stated in the thread, the patch doesn't give the script enough of a chance
as the time between closing the fd and the kill is too short and, for the
same reason, it may also cause existing correctly written scripts to suffer
data loss. I would prefer the solution using the callback (and handling the
relevant corner cases).

------=_Part_28262_5234422.1161858293607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Sorry to have caused the argument ;)  And despite having proposed it, =
I am not actually sure that I am still in favour of the patch.<br><br>The p=
roblem can (and indeed should) be fixed in the pass_persist script.&nbsp; U=
sing select, the call will return with the fd set and the subsequent read w=
ill result in&nbsp; EOF (another read will result in EPIPE error).&nbsp; Us=
ing poll, the call will return with POLLHUP set meaning that the fd has bee=
n closed/disconnected and the subsequent read will also result in EOF.&nbsp=
; The pass_persist script should handle this case and shutdown cleanly.&nbs=
p; I think this is part of the protocol and should be added to the document=
ation in the=20
snmpd.conf man page.&nbsp; It should also be ensured that the fd is not clo=
sed prematurely for any other reason.&nbsp; If a persistent script is used =
to avoid repeating a lengthy setup procedure (which I suppose is one fairly=
typical reason), this would defeat the purpose.
<br><br>The remaining question is whether the daemon wants to protect itsel=
f from an erroneous script and in particular the blocking waitpid call.&nbs=
p; I agree that any script should behave correctly (and according to the pr=
otocol) and that there are numerous ways that an erroneous script could blo=
ck/harm the daemon.&nbsp; You cannot cover all the cases, but I still think=
that the daemon should protect itself from this particular case as the blo=
cking waitpid call is potentially dangerous.&nbsp; The pass-through script =
should be given a chance to shutdown cleanly but if it doesn't take that ch=
ance (in a reasonable amount of time), then it should be forcefully shutdow=
n.&nbsp; But as already stated in the thread, the patch doesn't give the sc=
ript enough of a chance as the time between closing the fd and the kill is =
too short and, for the same reason, it may also cause existing correctly wr=
itten scripts to suffer data loss.&nbsp; I would prefer the solution using =
the callback (and handling the relevant corner cases).
<br>


------=_Part_28262_5234422.1161858293607--


--===============1836076483==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=...057&dat=121642
--===============1836076483==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders

--===============1836076483==--