[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[AWIPS #FDH-124056]: Installation error

 
> I was having problems so Michael suggested I switch from the general
> AWIPS repository to the development repository. When we re-install on
> a new workstation, should we continue using the development
> distribution or switch to the general repository?

At this point you should use the development repository, 
www.unidata.ucar.edu/repos/yum/awips2-dev/ since it is just about ready for 
public release.  At this point I consider it a beta and I have made it's 
location known to about a half-dozen people for testing.  I also taught the 
AWIPS II training workshop last week using thew 14.4.1 development release.

The reason it is a beta and not a wide release right now is that I am still 
trying to solve a problem with the Qpid JVM which occasionally crashes and is 
unable to restart on its own.



> During the installation I ran into a these issues:
> 
> 1. During the EDEX installation I saw this error:
> 
> Installing : awips2-maps-database-14.4.1-1n6.noarch
> 31/79
> Ambiguous output redirect.
> Ambiguous output redirect.
> --------------------------------------------------------------------------------
> \| AWIPS II Maps Database Installation - FAILED
> --------------------------------------------------------------------------------
> Check the installation log:
> /awips2/database/sqlScripts/share/sql/maps/maps.log
> 
> warning: %post(awips2-maps-database-14.4.1-1n6.noarch) scriptlet failed,
> exit status 1
> Non-fatal POSTIN scriptlet failure in rpm package
> awips2-maps-database-14.4.1-1n6.noarch


Interesting.  Can you copy me the specs of your machine? uname -a  

I have not seen this error message installing on CentOS 6.5 and 6.6.

Was this on a new machine without any existing /awips2 directories? 



> 2.  In the installation instructions, item 10 suggests using a command:
> "qpid-stat -q -S msg -L 3" and in the explanation of the output says:
> 
> If msg and msgIn are greater than zero, then Qpid is receiving messages
> from
> edexBridge for the dedoder/product indicated by the message queue name
> (e.g. Ingest.Grib ).
> 
> I am seeing a msgIn>0 but msg consistently is 0, and I am not seeing
> Ingest.Grib in my output:
> 
> Is everything OK?


Yes, qpid-stat looks fine.  msg is zero because all incoming messages (msgIn) 
have been processed (msgOut).  

You can sort qpid message queues by the number of incoming messages with the 
command:

qpid-stat -q -S msgIn

and you can print only grib queues with the command 

qpid-stat -q -S msgIn |grep -i grib

Basically if your EDEX server ever appears to be running slow, check that no 
queues are backlogged (where msg is continuously increasing, meaning more data 
files are coming in than can be processed/completed).  



> 3. In the output for edex status, I'm seeing an error message:
> 
> # edex status
> 
> [edex status]
> */awips2/tools/bin/edex: line 75: [: too many arguments*
> postgres    :: running :: pid 12585
> pypies      :: running :: pid 12632
> qpid        :: running :: pid 12676
> EDEXingest  :: running :: pid 9044 12835 12947
> EDEXgrib    :: running :: pid 9056 12833 12926
> EDEXrequest :: running :: pid 9064 12831 12914


This appears to be a bug, thanks for letting me know, I will look into it.



> 4. After I installed the CAVE client when I first attempted to run
> /awips2/cave/cave.sh as the awips user when the connection preferences
> dialog window popped up, I clicked OK, but the connection failed as there
> was no process listening on port 9581. I knew I'd opened the port on the
> firewall and the other two ports: 5672 and 9582 show up in the output of a
> netstat command. I figured I'd research more when I returned from a meeting.
> When I returned I was surprised to find a process was now listening on port
> 9581. The connection dialog completed successfully. I had a similar
> experience
> when I rebooted the machine: once I started LDM and EDEX manually,
> there was no process listening on 9581. If I waited a while, the process
> started. Did I miss something in the installation, or is this normal?

I suspect that the JVM just took an extremely long time to start up.  In the 
14.4.1 dev release I have finally configured the GFE server to start correctly, 
and it adds approximately 30-60 seconds to the JVM start time.  In the three 
log files in /awips2/edex/logs/ (edex-ingest-YYYYMMDD.log, 
edex-ingestGrid-YYYYMMDD.log and edex-request-YYYYMMDD.log) you will see a 
message like "EDEX ESB now operational" when the JVM has fully started and 
services are available on its ports.




> 5. The installation does not update the run level settings for a process
> which would start EDEX, QPID or httpd-pypies during boot, though there are
> processes to stop EDEX and QPID during shutdown, but NOT httpd-pypies.

You'll notice in the edex mananger (/awips2/tools/bin/edex) in the function 
edex_setup() the commented block for setting run levels.  Uncomment this block 
and run the command "edex setup" again and you should be good.  I will enable 
this in the dev repo soon.

        # run services on system startup
        #chkconfig edex_postgres --add
        #chkconfig httpd-pypies --add
        #chkconfig qpidd --add
        #chkconfig edex_camel --add
        #chkconfig edex_postgres on --level 235
        #chkconfig httpd-pypies on --level 235
        #chkconfig qpidd on --level 235
        #chkconfig edex_camel on --level 235




> There was no suggestion to do this in the installation instructions.
> Also during the installation process, I had occasion to stop EDEX and
> sometimes there would be pages and pages of messages something like "waiting 
> for
> ingest Grib to terminate." After some time, I would kill the running 
> processes.

I've noticed this as well and am working on a solution.  Another reason why 
14.4 is still beta.

Thanks for your thorough feedback on the installation.  Let me know how else I 
can help.

Michael 


Ticket Details
===================
Ticket ID: FDH-124056
Department: Support AWIPS
Priority: Critical
Status: Open