You are here

Ubuntu 14.04, repo not finding opsview package.

7 posts / 0 new
Last post
dgullage
dgullage's picture
Ubuntu 14.04, repo not finding opsview package.

Hello,

 

I have been attempting to install opsview-core on a 32-bit 14.04 ubuntu server distribution. I am familiar with LAMP applications for the most part, but it seems that the opsview package itself is not in the repository that I am trying to download from..

 

When I attempt to run apt-get install opsview I get one of these messages:

Package opsview is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'opsview' has no installation candidate

 

My /etc/apt/sources.list.d/opsview.list file has:

#Opsview Packages
deb http://downloads.opsview.com/opsview-core/latest/apt trusty main

I have run apt-get update many times. I added the GPG key info so it stopped complaining about that, but I'm not sure if that has much to do what is going on here.

 

The full output is:
# apt-get install opsview
Reading package lists...
Building dependency tree...
Reading state information...
Package opsview is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'opsview' has no installation candidate

# apt-cache search opsview

nagstamon - Nagios status monitor which takes place in systray or on desktop
opsview-agent - Opsview-specific nagios NRPE agent package.

#

I installed opsview-agent, but I need more than that one package to get this ito work...

Does anyone have any suggestions?  Does anyone else have OpsView working on Ubuntu 14.04? Would reverting to ubuntu 12.04 help?

 

Thanks!

 

Dan

dgullage
dgullage's picture
Re: Ubuntu 14.04, repo not finding opsview package.

Oh, I read that ubuntu 14.04 isn't supported yet.. oh well.

</close>

nick42
nick42's picture
They have "trusty" in the

They have "trusty" in the repo, but I am getting that same error (it's October now).

???

 

gab0078
gabriel.popa's picture
Same here, Ubuntu 14.04 with

Same here, Ubuntu 14.04 with fresh install - and getting the same result (opsview has no installation candidate).

smarsh
smarsh's picture
Opsview Core is end of life,

Opsview Core is end of life, please use the repository for Opsview Atom.

dgullage
dgullage's picture
I went with the latest LTS

I went with the latest LTS release. I generally use CentOS for enterprise servers, but debian/ubuntu could certainly handle the job. I had OpsView 3.1.0 on Ubuntu 8.04. I know packagement pretty well for both GNU (deb/apt*) and RedHat (rpm/yum). I ended up finding another bug and fixing it on the 3.1.0 server that was discretly fixed in the new version. 
I tried to borrow the first few lines of code from: https://secure.opsview.com/svn/opsview/trunk/opsview-core/bin/call_nmis

because the only PIDs that get stuck and end up having a parent process of 1 (init) are dead/unresponsive hosts which we want to keep just in case (not 100% sure why we have to).. Anyway, the first few lines in call_nmis are:
 

#!/bin/bash #A bunch of comments.. cmd=$1 shift # tidy up/kill collect processes that have a parent of init as these are # hung processes ps -u nagios -o pid,ppid,comm \ | awk '$2 == 1 && $NF ~ /nmis.pl.collect/ { print $1}' \ | xargs kill -9 1>/dev/null 2>/dev/null

Running this code choked on me, so I wrote a Perl script to do the same thing, and also log every process it kills:
 

#!/usr/bin/perl

@ps_output = `ps -u nagios -o pid,ppid,comm | grep nmis.pl`;

while($ps_output[$count] ne ""){
        #if one or more digits are found put them into memory, only if the digits are followed by one or more spaces, followed by the character 1, followed by more spaces, and finally nmis.pl.
        $ps_output[$count] =~ /(\d+)\s+1\snmis.pl/;

        #give $1 a unique name
        $dead_process = $1;
        #Make sure $dead_process is a valid number and verify that the pattern above matched. If not, move on to the next process.
        if($dead_process =~ /\d+/){
                open(LOG, ">>/usr/local/nagios/nmis/logs/nmis_cleanup.log");
                $date = `date +"[%m\/%d\/%y %H\:%M\:%S]"`;
                chop($date);
                print LOG "$date Had to kill hung process: \n";
                print LOG "USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND\n";
                $ps_hung = `ps auwx | grep nmis.pl | grep $dead_process | grep -v grep`;
                chop($ps_hung);
                print LOG "$ps_hung\n";
                close(LOG);
                #Kill it with signal 9 (KILL) since these hung processes will not respond to a normal interrupt
                system("/bin/kill -9 $dead_process");
        }
        $count++;
}

Now I have plenty of RAM to run the version I was having issues with before. Since I don't know how much longer I'm going to have to monitor this DC it's probably not worth my time checking out the new version. The new call_nmis just shoots any processes that got stuck in the head and doesn't log anything. I think they realized that it was going to be a pain to find the underlying cause of why dead/unresponsive hosts occasionally get hung and take up somewhere between 20-25MB of RAM which adds up in time.

Honestly I don't have VMWare and I'm limited to a couple spare machines I can use. I'd rather have them as standby systems for more important purposes.

On average this script runs via crontab once per day and kills 1-2 processes. It certainly prevents the system from running out of RAM since it only has 2G and 1.5G of SWAP.
 

dgullage
dgullage's picture
Wow, that came out ugly. It

Wow, that came out ugly. It looked okay when I was writing it but there was no preview window.

Anyway, I'm all set. Since I had some hosts getting stuck just because they didn't exist anymore or weren't responding, nmis.pl.collector would occasionally build up processes. Some of the non-existant hosts did it more often than others, it was very weird, just a bug in the old OpsView 3.1.0 I assume. Anyway, opsview-core had the code I needed to kill these orphaned PIDs. As I said, we only get 1-2 per day, so I just made a daily cron kill the orphan pids, and I've been logging it. I posted the code above. It works great, but no one is going to be able to read it the way it pasted. Let's try < code >:

#!/usr/bin/perl

#get processes for the user nagios, display pid #s, parent pid#s, and comments(names). Filter for processes named nmis.pl.
@ps_output = `ps -u nagios -o pid,ppid,comm | grep nmis.pl`;

while($ps_output[$count] ne ""){
        #if one or more digits are found put them into memory, only if the digits are followed by one or more spaces, followed by the character 1, followed by more spaces, and finally nmis.pl.
        $ps_output[$count] =~ /(\d+)\s+1\snmis.pl/;

        #give $1 a unique name
        $dead_process = $1;
        #Make sure $dead_process is a valid number and verify that the pattern above matched. If not, move on to the next process.
        if($dead_process =~ /\d+/){
                open(LOG, ">>/usr/local/nagios/nmis/logs/nmis_cleanup.log");
                $date = `date +"[%m\/%d\/%y %H\:%M\:%S]"`;
                chop($date);
                print LOG "$date Had to kill hung process: \n";
                print LOG "USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND\n";
                $ps_hung = `ps auwx | grep nmis.pl | grep $dead_process | grep -v grep`;
                chop($ps_hung);
                print LOG "$ps_hung\n";
                close(LOG);
                #Kill it with signal 9 (KILL) since these hung processes will not respond to a normal interrupt
                system("/bin/kill -9 $dead_process");
        }
        $count++;
}


I copied the logic from the link to call_nmis above which is a BASH script, but it didn't work for me so I just got it done quickly since I pretty much default to Perl if any other language doesn't work for me immediately.