Handling frontier rpm installation problems
===========================================

Last updated at: 21 September 2011
Written by dfront@cern.ch

The following attempts to explain how to detect and handle problems with frontier rpm installation.

If rpm installation goes well, you may not need to bother yourself with the following details.

Problems with installation of frontier-squid have been observed more, relative to other frontier rpms
and hence they are discussed here more.
Yet, the following explanations attempt to be generic; refer to all frontier rpms where relevant.

From here an on, 'rpm installation' may also refer also to 'rpm upgrade'.

In any case of frontier rpm installation problems, please do attempt to send a detailed log, explaining the problem,
to a frontier mail list (atlas-adc-frontier@cern.ch).

Dangling rpm entities:
    Upon some rpm installation problems,
    it may happen that an rpm failed to install, 
    but it has remaining traces that may seem to indicate that the rpm is installed:
    - Files
    - Processes
    - and 'rpm -q' indicates that the rpm is installed

Dangling installation:
    A dangling installation is the result of a failed rpm installation that failed to rollback and uninstall itself.
    Generally, if an rpm fails to install, it attempts to rollback and not to leave any trace:
    It removes files that it has created and does not leave any (dangling) process.
    This situation may be detected by the response to the following command not including the release that failed to install:
        rpm -q <rpm name>
    Example:
        After a clean failure to install frontier-squid-2.7.STABLE9-5.8.sl5,
        (and assuming that there was no prior installed release of frontier-squid,)
        the command
            rpm -q frontier-squid
        responds with an empty response 

    However, there are cases where rpm installation errors can not be fully undone automatically.
    This situation may be detected by:
    - Error messages at rpm installation
    - Combined with the response to the above command yes indicating the release that was attempted in install
    Example:
        frontier-squid-2.7.STABLE9-5.8.sl5

    (Details: In particular, as part of the rpm installation process,
    there is a %post scriptlet that is defined at the rpm .spec file.
    As opposed to errors at the %pre scriptlet, that may prevent the installation from completing,
    failures at %post do not cause the rpm to be uninstalled.
    At the most, a clear message may be issued to indicate the nature of the error and its consequences.)

Dangling upgrade:
    A dangling upgrade is the result of a failed rpm upgrade that failed to rollback and uninstall itself.
    The way rpms upgrade, is that they first install the new rpm release, and then remove the previous release.
    This implies, that there is a (hopefully short) time, during which, at normal installation,
    both new and previous releases of the rpm are installed.
    This may be detected by the response to the above command
    Example, when upgrading from frontier-squid-2.7.STABLE9-5.6.sl5 to frontier-squid-2.7.STABLE9-5.8.sl5
        rpm -q frontier-squid
    responds with 2 releases: the new and previous ones.
        frontier-squid-2.7.STABLE9-5.6.sl5
        frontier-squid-2.7.STABLE9-5.8.sl5
    At dangling upgrade, the previous situation persists after the upgrade 'finishes',
    (if the %post of the new release does not complete, 
    rpm does not count the new release as usable, and hence does not uninstall the previous release.)

    In the above case, frontier-squid-2.7.STABLE9-5.6.sl5 is still installed, 
    and may be running (happily)
    while frontier-squid-2.7.STABLE9-5.8.sl5 is dangling.

Cleaning a dangling installation:
    In order to clean a dangling installation, 
    one may attempt to uninstall the dangling installed release.

    Example:
        rpm -e frontier-squid-2.7.STABLE9-5.8.sl5

    In case of upgrade, and the previous release may continue running (hopefully happily).

    If the failure to uninstall is due to a failing scriptlet, 
    you may add the rpm --noscripts option, . e.g.: rpm -e --noscripts frontier-squid-2.7....

Dandling processes:
    Even after attempting to uninstall,
    there may be cases of dangling processes left over.
    Example:
        For frontier-squid, instead of getting two processes as a response to the following command
            ps -efw|grep squid|grep -v grep
            33471    32039     1  0 09:44 ?        00:00:00 //usr/sbin/squid -DFS
            33471    32041 32039  0 09:44 ?        00:00:00 (squid) -DFS
        in the case of dangling installed new release, there may be 4 processes, 2 of the new release and 2 of the previous one.
        (The more new process couple will have a bigger start time.)
    It may not be possible to kill dangling processes by:
        /sbin/service frontier-squid stop
    If after a service stop, squid processes remain running, 
    they are most certainly left over from a previous installation and will require a manual kill 
    e.g.: kill -9 [process_ID]