Novell Home

Debugging RedCarpet Problems

Novell Cool Solutions: Tip

Digg This - Slashdot This

Posted: 23 Apr 2004
 

Here are some tips that could be helpful in debugging RedCarpet problems. This info is coalesced from an rc-hackers@ximian.com thread (Joe Shaw, Tambet Ingo and other contributors). Enjoy! And if you have anything to add, please let us know.

  • Some useful basic commands
    • "rug get" or "rug get -d" lists the configuration file settings
    • "rug history" lists log entries and "rug history --help" lists more options/filters
    • "rug search" and "rug search --help" provide search options


  • Debug level. By default it's 4. The highest level is 6, and it outputs a TON of stuff. You can set it by running rcd with -d6 or using "rug set debug-level 6".


  • "rug dump". For dependency problems this is the best thing, since you can then load the dump in using the --undump option to rcd, and then you have all the same channels, packages, locks, etc. as the user. You can then try to run their transaction and see what happened.


  • The rug "info" and "what" commands are incredibly helpful at finding out relationships between packages. The "info" commands (info-requires, info-provides, etc.) tell you the properties of the package you provide. For example, "rug info-provides glib" will tell you everything glib provides. The "what" commands do the inverse: "rug what-provides libglib-1.2.so.0" tells you all the packages that provide that library.


  • If you're doing an installation and you can't figure out why a package, usually of a lower version, is being pulled in, try explicitly choosing the package using the channel:package notation (ie, "rug in xd2-pro:acroread"). Chances are there's a dependency problem that prevents it from being a valid solution.


  • Rug and red-carpet almost never crash. It's probably rcd that crashed, so always check the /var/log/rcd/rcd-messages file, *especially* if the rug or rc traceback include the file "ximian_xmlrpclib.py" and make sure that the problem is or isn't in rcd. This'll fix a whole round-trip in trying to figure out what's wrong.


  • RPM is buggy. If a post-install script fails, you'll have to copies of the package in your RPM database. There's no getting around it other than making sure the packagers write postinst scripts which never fail. If it ever happens with an XD2 package, it's a bug for the XD2 team.


  • RPM is buggier still. RPM 4.1 as shipped in Red Hat 8.0 and RPM 4.2 as shipped in Red Hat 9 sometimes lock up. In those cases, you need to kill everything RPM-related (including rcd), rm /var/lib/rpm/__db.*, and rerun whatever you were running. You'll likely have multiple entries in your RPM database for packages that were installed in that transaction up to that point. There are fixed packages (RPM 4.1.1 for Red Hat 8.0, and a newer revision of RPM 4.2 (4.2-1, as opposed to 4.2-0.69) for Red Hat 9) which don't hang. Red Hat hasn't issued errata for these... not totally sure why other than internal RH politics.


  • Additional dependency resolver info. By running rcd with RCD_DEBUG_DEPS you can get all the resolver info, not just the "important" ones. You can get total spew of the resolving process by setting RC_SPEW. You can limit how long dependency resolution takes (somewhat) by setting RC_DEPS_TIME (in seconds).


  • If you use word 'transaction' in bug report, it is very important to mention what started it (client or server). These are totally different code bases.


rcd-modules

  • If you have a problem with system information (software, hardware) or transactions initiated by server: Does the client have rcd-modules installed? When reporting a bug, it's rcd-modules component (not rcd).


  • All software information is sent to server with at least 1 minute delay.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell