The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Urchin stopped working?

Discussion in 'General Discussion' started by wowway1, May 24, 2005.

  1. wowway1

    wowway1 Member

    Joined:
    Jul 15, 2004
    Messages:
    18
    Likes Received:
    0
    Trophy Points:
    1
    Hmmm, as of 5/19 Urchin stopped working on my server. Stats are not being updated for all domains. How can I fix this?
     
  2. nickb

    nickb Well-Known Member

    Joined:
    Feb 25, 2005
    Messages:
    347
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    India
  3. BenThomas

    BenThomas Well-Known Member

    Joined:
    Feb 12, 2004
    Messages:
    598
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Houston, Texas USA
    cPanel Access Level:
    Root Administrator
    That thread is pretty dated. I'll post some additional Urchin troubleshooting tips.
     
  4. BenThomas

    BenThomas Well-Known Member

    Joined:
    Feb 12, 2004
    Messages:
    598
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Houston, Texas USA
    cPanel Access Level:
    Root Administrator
    Currently, Urchin works pretty flawlessly with cPanel, but occasionally problems do arise. Any thorough investigation into a failing Urchin should begin by grokking cpanellogd. This script is the heart of all cPanel log processing and is responsible for processing the log files for Urchin. In a normal Urchin installation, the Urchin-modified Apache server handles the administrative interface as well as coordinates the processing of log files for Urchin stats. In a cPanel installation, cpanellogd replaces the Urchin web server and processes the logs for Urchin right along with the stats for Webalizer, Awstat, and the like. Three of the most common reasons why Urchin fails are system load, a corrupted filesystem, or the log file is too large to process.

    Before beginning any troubleshooting, I like to make sure the system is up to date. I run updatenow. If the scripts directory is out of date, then I usually assume that the system is out of date as well. Otherwise I just check their cPanel version against the latest available.

    Locating the Problem:
    The first thing I do is turn up the verbosity of the stats_log. This is accomplished by increasing the value of statsloglevel (cpanel.config) to anything greater than 5 (usually set it to 99). I then run the logs for a user known to have the issue using runweblogs:

    Code:
    root@localhost [~]# /scripts/runweblogs username
    This outputs most of the logging to the terminal, so you can pick up on any errors. More often than not, you can easily see the problem here.

    I also check the log file itself for its size and any file corruption. cpanellogd easily handles log files of several hundred megabytes, but I've seen the individual stats programs choke on files over 1 gigabyte (as you can imagine). I check for corruption by cat'ing through the file to locate any abhorrent characters. Usually, when a file is corrupt it is huge as well.

    Repairing the Problem:
    The easiest problem to fix is an overloaded system (well log processing that is). The value of extracpus (cpanel.config) should be increased to reflect their average system load. You should also make them aware of the fact that their system performance for other services will likely be degraded while the logs are being processed. Unfortunately, the only ways around that are to not process the logs or increase the available system resources.

    If the log file is too large to process, then I believe the safest thing to do is to seperate out the unprocessed month into a new log file. I accomplish this by grep'ing the pertinent month out of the file, renaming the old log file and replacing it with the new one. I think it's good form to gzip the old log file as well; I've seen 1.6G files compress down to 72M. You'll need to HUP Apache after moving the log files around as well. Afterwards I reprocess the logs for the user using runweblogs to verify the fix.

    If the log file is corrupt, then their drive will require an old fashioned fsck'ing. On Red Hat systems this is usually accomplished by touching the file /forcefsck and rebooting. I recommend to make sure they are doing the reboot as the system may not come back online without some on site intervention.

    Additional Issues
    License Limitations
    An additional common complaint is that Urchin is not processessing logs for all domains. This is usually one of the easiest to resolve because there is no "resolution". Urchin is licensed per domain, so once the server has exhausted it's pool of profile licenses, additional profiles will not be added and subsequently their Urchin stats will not be generated. The only option in this case is to remove an existing profile and add in a new one for the domain that you'd like to have Urchin stats for (you could also purchase an additional license from Urchin as well)
    1. Export Database to XML (/usr/local/urchin/util/uconf-export -f /tmp/urchin.xml)
    2. Grep the XML for your domain that has an issue. It's Logfile configuration should be present.
    3. Locate a working profile section for a domain that you're not concerned about having Urchin stats for. Edit it, changing the information to that of the domain that you want Urchin stats for.
    4. Import the profile so that it will be added to the database (/usr/local/urchin/util/uconf-import -f /tmp/urchin.xml).
    If your Urchin setup is at its license limit, and you attempt to import an XML file that adds an additional profile without removing another, this is the error message your will receive:
    Code:
    Failure will yield an error:
    License limit reached.
    removed 0 records. 
    added 0 records. 
    edited 0 records.
    That's why I recommended editing an existing unnecessary profile earlier.

    Bad geodata
    I believe this issue results from an Urchin upgrade. In the user's urchin data directory (/home/username/tmp/urchin/data) there should be a symlink to /usr/local/urchin/data/geodata. In some cases this will instead be a file without any permission (000), preventing Urchin from running.

    Relevant Files/Directories:
    /var/cpanel/cpanel.config <- primary cPanel configuration file
    /usr/local/urchin <- Urchin installation directory
    /usr/local/urchin/util <- directory containing command line utilities
    /usr/local/apache/domlogs <- user log file location
    /usr/local/cpanel/logs/stats_log <- log processing log file
    /usr/local/cpanel/cpanellogd <- cPanel log processing script
    /scripts/runweblogs <- processes logs for user, displays status
    /scripts/runstatsonce <- sets env to ignore last run, starts cpanellogd

    Links:
    Urchin Documentation
    uconf-driver
     
  5. nickb

    nickb Well-Known Member

    Joined:
    Feb 25, 2005
    Messages:
    347
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    India
    Great.......
     
  6. Brando

    Brando Member

    Joined:
    Nov 6, 2003
    Messages:
    7
    Likes Received:
    0
    Trophy Points:
    1
    Hi,

    My urchin also stopped updating stats from a certain date (17/05).

    I have increased the statsloglevel in cpanel.config as advised.

    /scripts/runweblogs username produced only this significant error :

    chmod: failed to get attributes of `/usr/local/urchin/data/conf/uconf.log': No such file or directory

    I also noticed that my profiles will be automatically deleted from time to time resulting in the error :

    Unable to get profile id from configuration database

    This happens when I run /scripts/runweblogs. My logfile for this particular username is only 29MB so I do not think this could be a problem related to a extra large file size. I have cat-ted the entire logfile to check for corruption but everything seems to be in order, even for the date which urchin stopped updating the stats.

    I have a 100-domains license and there are less than a 100 domains on this server with only one profile added. I exported the configuration to a XML file and a check on this file revealed that I have 2 profiles, one for www.domain.com and another for domain.com.

    Could this be the problem? If that is the case, which domain profile should I delete? And why does urchin keep removing the profile ID from the configuration database. I had to manually re-add the profile everytime that happens, and the stats just stopped updating from 17/05.

    Please assist. :(
     
Loading...

Share This Page