Two simple TCPIP / FTPSERVE questions.
This is very basic and simple but I can't seem to see the answer anywhere (although it is probably staring me in face). Once TCPIP has decided that it has tried to restart a server (FTPSERVE) the maximum number of time and abandons further attempts - how can I reset this once the problem has been resolved? We rely very heavily on incoming FTP but we have found that FTPSERVE does not like receiving files onto a corrupt disk and sulks heavily (Sorting the cause of the corruption is a separate problem and not as simple as it first appears). Is there any easy way (or a tool) to monitor that FTPSERVE is currently functional so that remedial action can be taken automatically (in the middle of the night) if it is not? Colin Allinson VM Systems Support Amadeus Data Processing GmbH IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the individual or entity shown above as addressees. It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws. If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system. Amadeus Data Processing GmbH Geschäftsführer: Eberhard Haag Sitz der Gesellschaft: Erding HR München 48 199 Berghamer Strasse 6 85435 Erding Germany
Re: Two simple TCPIP / FTPSERVE questions.
On Wednesday, 07/06/2011 at 04:25 EDT, Colin Allinson cgallin...@amadeus.com wrote: This is very basic and simple but I can't seem to see the answer anywhere (although it is probably staring me in face). Once TCPIP has decided that it has tried to restart a server (FTPSERVE) the maximum number of time and abandons further attempts - how can I reset this once the problem has been resolved? From Usage Note #1 for MaxRestart: If a user is restarted MAXRESTART times, the TCP/IP server will send a message to the INFORM list and stop restarting the user. After that, you can tell the TCP/IP server to attempt to restart the user another MAXRESTART times by dynamically specifying the user's PORT statement without the NOAUTOLOG operand. So you can use OBEYFILE or NETSTAT OBEY. We rely very heavily on incoming FTP but we have found that FTPSERVE does not like receiving files onto a corrupt disk and sulks heavily (Sorting the cause of the corruption is a separate problem and not as simple as it first appears). Is there any easy way (or a tool) to monitor that FTPSERVE is currently functional so that remedial action can be taken automatically (in the middle of the night) if it is not? You could watch FTPSERVE's console for unexpected ending conditions. You may also wish to use FTP 127.0.0.1 (loopback) with the program stack and the EXIT parameter to see if FTP is up. Or just establish a TCP connection to port 21, look for the welcome banner, then issue QUIT. Alan Altmark Senior Managing z/VM and Linux Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Two simple TCPIP / FTPSERVE questions.
Very simple way: set up a small Linux instance and install Nagios on it. Configure a FTP probe in Nagios, and configure a notification to a user on the VM system. The Nagios system will test the FTP server by connecting and attempting to transfer a small file periodically. If it fails, it sends a notification email. Handle the email with PROP. That approach tests not only whether the server is logged in, but whether it's actually functioning. Works well for lots of things, and is low-cost (no cost if you run Debian or Fedora for Z).
Re: Two simple TCPIP / FTPSERVE questions.
Alan, Thanks - that is great. I can work from that. Colin Allinson VM Systems Support Amadeus Data Processing GmbH
Re: Two simple TCPIP / FTPSERVE questions.
David Boyes dbo...@sinenomine.net wrote:- Very simple way: set up a small Linux instance and install Nagios on it. Configure a FTP probe in Nagios, and configure a notification to a user on the VM system. The Nagios system will test the FTP server by connecting and attempting to transfer a small file periodically. If it fails, it sends a notification email. Handle the email with PROP. That approach tests not only whether the server is logged in, but whether it?s actually functioning. Works well for lots of things, and is low-cost (no cost if you run Debian or Fedora for Z). David, I am afraid we are in lock down here (essential maintenance only) so no chance of installing a new LINUX server. However, I could use your idea from an existing hartbeat server between VM systems. Colin Allinson VM Systems Support Amadeus Data Processing GmbH
Re: Two simple TCPIP / FTPSERVE questions.
On Wed, Jul 6, 2011 at 4:35 PM, David Boyes dbo...@sinenomine.net wrote: That approach tests not only whether the server is logged in, but whether it’s actually functioning. Works well for lots of things, and is low-cost (no cost if you run Debian or Fedora for Z). Depending on how the FTP server fails, you might also see it in your performance monitor... With anything that monitors a service by probing, the issue is only noticed after some time. Once you increase the polling to detect it quick enough that you still have time to fix it within SLA, the process uses a lot of resources (in a former life we tested e-mail delivery like that until 50% of our traffic was probes and 90% of the outages were caused by them...) Using SCIF on the FTPSERVE userid, PROP can watch the console and notice the outage immediately. CMS gives you easy tools to arrange the restart of the server. Running a Linux virtual machine with agents just to poll the FTP server is only no cost when you have too much resources and spare time. | Rob
Re: Two simple TCPIP / FTPSERVE questions.
Depending on how the FTP server fails, you might also see it in your performance monitor... Also true. OTOH, there are failure modes (such as the one Colin mentioned about getting unhappy with a minidisk) that won't show up in the console log or will show misleading symptoms (large buffer exhaustion, for example). Running a Linux virtual machine with agents just to poll the FTP server is only no cost when you have too much resources and spare time. So run it on an external system, where the cost on Z is periodically another client session. Either way, you get a end-user perspective of the behavior you want to test rather than inferring it from secondary sources. There are also likely to be other services that need similar testing, which could benefit from a similar approach, and there is substantial existing code that can do the job without writing a bunch of stuff from scratch. It takes a lot less time to configure an existing tool than to gather the information to second-guess what is happening from the console.
Re: Two simple TCPIP / FTPSERVE questions.
David, I am afraid we are in lock down here (essential maintenance only) so no chance of installing a new LINUX server. However, I could use your idea from an existing hartbeat server between VM systems. World work, I'd think. That'd also catch the socket timeout delay problem if/when you have more than a few thousand connections waiting for the TCP close processing to complete.
Re: Two simple TCPIP / FTPSERVE questions.
You've been wearing your Linux appliance hat too long. Much lighter-weight would be a few lines of Rexx with or without Romney's FTP package, running periodically as a task in your automation solution or a standalone (CMS) VSM. -- Mike Harding z/VM System Support mhard...@us.ibm.com mike.b.hard...@kp.org mikehard...@mindless.com (925) 926-3179 (w) (925) 323-2070 (c) IM: VMBearDad (AIM), mbhcpcvt (Y!) The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 07/06/2011 07:35:19 AM: From: David Boyes dbo...@sinenomine.net To: IBMVM@LISTSERV.UARK.EDU Date: 07/06/2011 07:35 AM Subject: Re: Two simple TCPIP / FTPSERVE questions. Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU Very simple way: set up a small Linux instance and install Nagios on it. Configure a FTP probe in Nagios, and configure a notification to a user on the VM system. The Nagios system will test the FTP server by connecting and attempting to transfer a small file periodically. If it fails, it sends a notification email. Handle the email with PROP. That approach tests not only whether the server is logged in, but whether it’s actually functioning. Works well for lots of things, and is low-cost (no cost if you run Debian or Fedora for Z).
Re: Two simple TCPIP / FTPSERVE questions.
been wearing your Linux appliance hat too long. Much lighter-weight would be a few lines of Rexx with or without Romney's FTP package, running periodically as a task in your automation solution or a standalone (CMS) VSM. Perhaps. OTOH, up and usefully running in less than 10 minutes with no development time has it’s appeal. But, I guess I’m getting old enough that rolling my own isn’t as much fun any more. I suggested A solution, not THE solution. Lots of ways to boil this lobster. -- db
