>From: "David B. Bukowski" <address@hidden> >Organization: COD >Keywords: 200106202104.f5KL4N116106 Dave, re: what doesn't work on Linux that works everywhere else >What specifically are we looking at? I might be able to figure it >out. :) If not at least go thru some digging around and find something Here is what happens: o a client application makes a request for sounding data to a remote server o inetd (or xinetd on RedHat 7.x Linux) gets the interrupt on either port 500 (uncompressed ADDE) or 503 (compressed ADDE); it then starts whetever program it was configured to start. This will be the script ~mcidas/bin/mcservsh o mcservsh reads the contents of ~mcidas/.mcenv to get environment information needed to run McIDAS applications; it then execs the McIDAS executable 'mcserv' o mcserv reads the request from the client and then decides on what ADDE server to start. In the case of sounding requests, the server that is started is vpserv (vertical profile server) o vpserv looks at the request that the client made and then acts on it; the way it acts on the request is fundamentally different, however, from the way other ADDE servers work... if the client requested full sounding data (mandatory AND significant level upper air data), then vpserv will make ADDE server calls to the McIDAS point server, first for the mandatory level data and then for the significant level data. All other McIDAS ADDE servers would read directly from data files at this point. vpserv is the only server that fulfills an incoming data request by making two, consecutive server requests o vpserv gets all of the mandatory level data from the point source server and then shuts down that transaction; as it gets the data from the point source server, it is sending it back to the client; this all seems to proceed smoothly. After all of the mandatory level upper air data has been received by vpserv and sent to the client, vpserv makes a request from the point server for the significant level data o at some point during the read (from point server) / write (to the client) the connection through the port is broken. The breaking of the connection is not initiated by vpserv, nor is it initiated by the client. An 'strace' of the goings on of vpserv and the equivalent on the client machine (e.g., an strace for Linux; a truss for Sun Solaris; etc) shows that both vpserv and the client are "suprised" by the connection going away. The client is in a read look that gets an error; vpserv is in a read/write loop when the write starts failing. It is as though the OS has shut down the pipe through which vpserv is communicating back to the client. Why this would happen is unknown. I should point out that transactions through the remote ADDE server for other data types (e.g., image, single point (not sounding), grid, etc.) work with no problems in Linux. Also, the exact same McIDAS code built and run on RedHat 5.2 runs perfectly. It is almost as if the shutting down of the server request for mandatory level data from vpserv is somehow triggering something in the OS to shut down the connection through the port that vpserv is using to communicate with the client. If you are game for some exploring, it would be very useful to find out if there was any reworking of signals in versions of Linux between RedHat 5.2 and 6 (the change may actually be between RedHat 6.0 and 6.1; I don't know and I can't test this since I don't have a RedHat 6.0 system to use for testing). If the change was not in signals, then what major reworking was done inbetween these versions of Linux that would cause _something_ to shut down the connection of a process that was communicating through an open port? re: logs >Jun 21 13:04:21 weather pnga2area: Starting Up >Jun 21 13:04:21 weather pnga2area: output file >pathname: /home/data/mcidas/AREA1140 >Jun 21 13:04:21 weather pnga2area: unPNG:: 57277 322320 >5.6274 >Jun 21 13:04:21 weather pnga2area: Exiting These logs should be going into the ~ldm/logs/ldmd.log file. The invocation for pnga2area does not say where logging should occur, so it should go to the same place as the LDM logging: MCIDAS ^pnga2area Q. (..) (.*) (.*) (.*) (.*) (........) (....) PIPE -close pnga2area -v -d /home/data/mcidas -r \1,\2 Now, one could force logging into ~ldm/logs/ldmd.log by specifying the -l flat to pnga2area (and other ldm-mcidas decoders): MCIDAS ^pnga2area Q. (..) (.*) (.*) (.*) (.*) (........) (....) PIPE -close pnga2area -vl /home/ldm/logs/ldmd.log -d /home/data/mcidas -r \1,\2 but this shouldn't be necessary. Hmm... I just logged onto weather and see that ALL LDM logging is going to syslog: Jun 21 12:43:01 weather cdstats: Connection from cdstats.cod.edu Jun 21 12:43:01 weather cdstats: Connection reset by peer Jun 21 12:43:01 weather cdstats: Exiting Jun 21 07:43:01 weather sendmail: NOQUEUE: Null connection from cdstats.c od.edu [10.11.0.63] Jun 21 12:43:28 weather pqact: child 30776 exited with status 2 Jun 21 12:43:47 weather pqact: child 30898 exited with status 2 This means that syslog.conf is not setup the way we are used to for the LDM. A quick look on your machine shows that there are ~ldm/log/ldmd.log* files, but they have not been updated since April 17. Also, the ownership on the ldmd.log.1, ldmd.log.2, etc. files was incorrect; they were owned by root when they should be owned by ldm. re: continuing with syslog discussion >actually not running syslogd running syslog-ng been trying to figure out >the filtering configuration on it lately so it basically logs EVERYTHING >into debug i guess... well all the ldm stuff that normally goes in >~ldm/logs ends up in /var/log/debug since it is the DEBUG "channel" ldm >sends stuff to. I just chatted with Anne Wilson about your use of syslog-ng, and we were in agreement that we don't know enough about syslog-ng/syslog-ng.conf to be able to help you. re: leaving ports 500 and 503 open >I'll leave them open but would like to know if theres specific machines or >a netblock i can narrow access down to... Otherwise i'll just leave them >open. How about right now you leave them open. This will allow me to work from home during the troubleshooting phase for the sounding serving problem. Later, you could cut down access to those domains you wouldn't mind serving data through ADDE. Tom
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.