[syslinux] TFTP forking thousands of processes
Geert Stappers
stappers at stappers.nl
Tue Nov 13 12:20:07 PST 2012
On Tue, Nov 13, 2012 at 06:45:29PM +0100, Geert Stappers wrote:
> On Tue, Nov 13, 2012 at 01:49:46PM +0100, Nikola Ciprich wrote:
> >
> > We were trying to simulate the problem on test virtual guest and successfully
> > reproduced it:
> >
> > - VM got setup as tftp server (tftp started as xinet service, details below)
> > - on host, we've blocked all outgoing tftp traffic using iptables.
> >
> > then trying tftp request from some other machine spawns hanging tftp process
> > (running client 1000 times spawns 1000 in.tftpd processes)
>
> > Anyways, I wonder whether forking so many processes hanging on select() is correct behaviour.
See below
> > My inet configuration looks like this:
> >
> > service tftp
> > {
> > disable = no
> > socket_type = dgram
> > protocol = udp
> > wait = yes
> > user = root
> > server = /usr/sbin/in.tftpd
> > server_args = -s /tftpboot -v -v -v -c
> > per_source = 11
> > cps = 100 2
> > flags = IPv4
> > instances = 500
> > }
> >
> > Which I'd undetstand that no more then 500 in.tftpd processes should be spawned.
> > I guess tftp is forking on it's own, right? Is it possible it could block somewhere
> > unable to send replis, but forking on (repeated) requests?
> >
> > Does somebody have an idea on where the problem could be,
> > or how should I proceed with debugging?
>
> I would go for the TFTP server "stand alone", so not as a inetd proces.
>
On second thought, that might give the same result.
TFTP is a some odd network protocol.
server listens on port 69
client invites from port N the server at port 69
client waits on port N for server
server picks a port, say port M and contacts client at port N
server waits on port M
client recieves on port N from server port M
client sends from N to port M at server
server recieves on port M from client port N
server sends from M to port N at client
client recieves on port N from server port M
client sends from N to port M at server
server recieves on port M from client port N
server sends from M to port N at client
client recieves on port N from server port M
client sends from N to port M at server
I assume that each "listen on port M" is done with a new forked process.
I think that is a sane design decission.
Back to the original posting.
My advice: allow the clients only a power up or once a hour to fetch config files.
Stappers
More information about the Syslinux
mailing list