Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I maintain a server that receives data on many ports using xinetd in tcp mode. The data is processed by a perl script. Twelve of the 16 clients that connect to my server that way, apparently also run monitoring software against the same ports. I see two connections every five seconds on each of those twelve ports in addition to the one that stays connected all the time. These extra two connections disconnect immediately as soon as they have a successful tcp connection. The Perl script also starts up and shuts down every time there is one of these extra tcp connections. I assume this is causing a lot of overhead. I want to keep xinetd from starting the Perl script on these extra connections. I figure if there was a way to delay the starting of the Perl script for one second like using a sleep command in a shell script to start the Perl script then that would vastly reduce the overhead. Is there a better way to do it using an xinetd directive? One that would delay the starting of the server until data was received or for one second should be all that is needed.

I guess I'm supposed to post what I did to solve this that has been unsuccessful so far and because I didn't, the question got voted down. So just to be clear, I spent about an hour Googling, a half hour reading man pages and another half hour running a test using a shell script to see if some kind of piping or redirection would solve the problem. While I was Googling for information about this problem the only thing I did find out was that others have seen this kind of activity in their logs in connection with monitoring of the ports by the client side. I don't have an easy way to test this outside of production so I was hoping someone else had some experience with this (It can't be that rare) and would be able to share their solution so I could have some more confidence before trying the "sleep one second" thing in production and seeing if my overall load went down.

Here is a snippet of the messages log from the test box that is very similar to prod but only has three open ports.

Aug  9 23:27:42 box xinetd[5082]: START: adt-client1 pid=19988 from=172.x.x.x
Aug  9 23:27:42 box xinetd[5082]: EXIT: adt-client2 status=0 pid=19987 duration=0(sec)
Aug  9 23:27:42 box xinetd[5082]: EXIT: adt-client1 status=0 pid=19988 duration=0(sec)
Aug  9 23:27:42 box xinetd[5082]: START: adt-client3 pid=19989 from=172.x.x.x
Aug  9 23:27:42 box xinetd[5082]: EXIT: adt-client3 status=0 pid=19989 duration=0(sec)
Aug  9 23:27:47 box xinetd[5082]: START: adt-client2 pid=19990 from=172.x.x.x
Aug  9 23:27:47 box xinetd[5082]: START: adt-client1 pid=19991 from=172.x.x.x
Aug  9 23:27:47 box xinetd[5082]: EXIT: adt-client2 status=0 pid=19990 duration=0(sec)
Aug  9 23:27:47 box xinetd[5082]: EXIT: adt-client1 status=0 pid=19991 duration=0(sec)
Aug  9 23:27:47 box xinetd[5082]: START: adt-client3 pid=19992 from=172.x.x.x
Aug  9 23:27:47 box xinetd[5082]: EXIT: adt-client3 status=0 pid=19992 duration=0(sec)
Aug  9 23:27:52 box xinetd[5082]: START: adt-client2 pid=19993 from=172.x.x.x
Aug  9 23:27:52 box xinetd[5082]: START: adt-client1 pid=19994 from=172.x.x.x
Aug  9 23:27:52 box xinetd[5082]: EXIT: adt-client2 status=0 pid=19993 duration=0(sec)
Aug  9 23:27:52 box xinetd[5082]: EXIT: adt-client1 status=0 pid=19994 duration=0(sec)
Aug  9 23:27:52 box xinetd[5082]: START: adt-client3 pid=19995 from=172.x.x.x
Aug  9 23:27:52 box xinetd[5082]: EXIT: adt-client3 status=0 pid=19995 duration=0(sec)
Aug  9 23:27:57 box xinetd[5082]: START: adt-client2 pid=19996 from=172.x.x.x
Aug  9 23:27:57 box xinetd[5082]: START: adt-client1 pid=19997 from=172.x.x.x
Aug  9 23:27:57 box xinetd[5082]: EXIT: adt-client2 status=0 pid=19996 duration=0(sec)
Aug  9 23:27:57 box xinetd[5082]: EXIT: adt-client1 status=0 pid=19997 duration=0(sec)
Aug  9 23:27:57 box xinetd[5082]: START: adt-client3 pid=19998 from=172.x.x.x
Aug  9 23:27:57 box xinetd[5082]: EXIT: adt-client3 status=0 pid=19998 duration=0(sec)

A typical xinetd connection is configured like this:

service adt-client2
{
    disable = no
    port                    = 5070
    socket_type             = stream
    protocol                = tcp
    flags                   = KEEPALIVE
    wait                    = no
    user                    = root
    server                  = /opt/receivers/adt/hl7_receive.pl
    server_args             = client2
}
share|improve this question
    
Why do your clients monitor your software? have you considered monitoring these services yourself (using snmp's proc directive, for example) and letting your clients poll that OID instead? They wouldn't connect directly to the xinetd services unless necessary. –  dawud Aug 10 '13 at 7:15
    
Unfortunately the clients are run by very large institutions with inflexible IT departments and it would be difficult, if not impossible, to get all of them to change their monitoring policies. –  WDRev Aug 10 '13 at 20:36
    
I edited the question to add my previous research and testing. If anything is unclear about the question, please comment with a question so I can clarify. –  WDRev Aug 11 '13 at 18:08
    
So, you aren't sure how much extra load you have from these extra monitoring connections, and you aren't even sure that they are for monitoring! You should determine exactly what is going on, and what effect it's having, before you decide what to do about it. –  Michael Hampton Aug 11 '13 at 18:27
    
Yes that is true. I am only assuming that firing up the Perl interpreter from a shell 288 times per minute is causing a lot of load and that eliminating that load would be helpful. If anyone has any insight as to whether or not it would be a bad idea to avoid that activity, and most importantly, how that could be accomplished, please leave your helpful comments or answers. –  WDRev Aug 11 '13 at 19:18
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.