Issue 62176 - triggerscript goes to endless loop because of defunct rpm process that is created when installing with yast on SuSE
Summary: triggerscript goes to endless loop because of defunct rpm process that is cre...
Alias: None
Product: Installation
Classification: Application
Component: ui (show other issues)
Version: OOo 2.0.2
Hardware: All Linux, all
: P3 Trivial with 3 votes (vote)
Target Milestone: OOo 3.0
Assignee: Olaf Felka
QA Contact: issues@installation
Keywords: oooqa
Depends on: 61569
  Show dependency tree
Reported: 2006-02-16 21:27 UTC by kingshome
Modified: 2008-10-22 11:58 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description kingshome 2006-02-16 21:27:38 UTC
I'm using Suse linux 9.2, with KDE 3.51.

I've come across several installation problems, which are listed below.  If they
should be entered as separate issues, please inform me and I will file them

I have previously installed 2.0.2rc1 in a separate test user area using
commandline instuctions with no problems.

However, I decided to try and install it as I have all previous versions, using
Yast2 in Suse.  I know what the instructions are on the ooo site; however, I do
not think I am the only one who will try using the tools in the distribution for
installing rpms, and I believe it's worth testing this out.  I have previously
had no trouble using Yast2 to install or update ooo.

1  I first of all tried an update with Yast2.  My installed version was 2.0.1,
and at first everything seemed to be working fine.  However, when Yast2 reached
the rpm for Core01-2.0.2, it hung.  There was occasional disk activity, but no
progression in the installation.  After several minutes, I killed Yast, and
started again.

2  Since the update hadn't worked, I used yast to deinstall openoffice 2.0.1
completely.  In addition, I deleted the /opt/openoffice2 directory completely
(there were some files in a fonts directory and the dictionary directory)

3  I then tried to use Yast to install ooo 2.0.2rc1.  Again the installation
seemed to progress satisfactorily, but when it reached the rpm, it again hung, with some disk activity.  After 15
minutes I killed Yast, restarted it again and uninstalled the rpms that had been
installed and then repeated the installation process.  Again it hung at, and had to be killed.

4  I then uninstalled rpms that had been installed, and used the command line
method on the ooo site.  This went through smoothly, but ended with an error

"No theme index file in '/opt/kde3/share/icons/locolor'
If you really want to create an icon cache here, use --ignore-theme-index"

Since I had no idea what this referred to I ignored it (with fingers crossed)
and ran ooo.  Seems to be ok.
Comment 1 Olaf Felka 2006-02-17 09:25:28 UTC
I can't reproduce with Suse 9.1 and KDE 3.2.1. I don't have 9.2 for testing.
@  cloph: Any idea that might help?
Comment 2 dennybeyer 2006-02-18 12:56:43 UTC
I have the same problem as decribed under 1 with core01 package in yast2 on SuSE
9.3(standard install, all updates). Update used to work fine with all previous
developer version of 1.9.X.
Comment 3 kingshome 2006-02-21 19:08:06 UTC
I've tried again with ooo 2.0.2 rc2, and got exactly the same results when
trying to use Yast to either update or install from new.
Comment 4 dennybeyer 2006-02-21 23:34:27 UTC
Same here(Suse9.3, all updates): new attempt using rc2 shows the same as befor!
Packages were installed using yast package manager until package Core01. Yast
shows 100% of this package is installed, but doesn't go on to the next package
and doesn't respond at all. 
Since this prevents people from installing OOo, priority should be set to P1!
Hopefully one of the packager reads it and will fix it befor the release.
Comment 5 lohmaier 2006-02-22 01:16:25 UTC
The message
"No theme index file in '/opt/kde3/share/icons/locolor'
If you really want to create an icon cache here, use --ignore-theme-index"

is informatinal only (no indicator of failure or error). You have a image-cache
where not index-theme file is. That doesn't really make sense and the default
behaviour of gtk-update-icon cache is to skip this directory with the above message.

I did not have time to check with yast yet, but since it works on the
commanline, I guess this is a bug in yast, not in rpm or in one of the packages.

I don't have any idea why it should hang on the core01 package either, since
that neither contains any scripts or triggers.

I only have SuSE 10.0 here (download version, and it is not installed currently)
so can anybody tell me whether the problem occurs there as well, or do I have to
get 9.X?
Comment 6 kingshome 2006-02-22 08:20:10 UTC
A couple of suggestions of how I could help:

1.  I can let you have the yast logs if they would be of use.  If you let me
know which ones - or simply the whole log directory - I can submit them as an
attachment or send them direct.

2.  Would it be worth asking on a relevant Suse list for confirmation or
otherwise? If so I will happily post a request for help.
Comment 7 kingshome 2006-02-23 16:20:28 UTC
Tested on 2.0.2 rc3.  Same results.
Comment 8 nospam4obr 2006-02-26 09:59:41 UTC
@cloph: what about removing 'locolor' from the list themes - just to check
whether the console output is really the problem ? Since locolor is KDE only it
is very unlikely to have a gtk icon cache anyway .. 
Comment 9 lohmaier 2006-02-26 17:05:13 UTC
Im 99% sure that the gtk-update-icon-cache message is NOT related to the problem
of yast hanging up. 
If it was, then it would be a massive bug in yast. (Since 1st of all it should
not hang at all and 2ndly it would hide messages printed to stderr - that would
be a huge bug by itself)

Ans although locolor might be KDE-specific, there still may applications making
use of an icon-cache (that is not Gnome or GTK-only). 

And as the message from the reporter shows, there /is/ an icon-cache present. If
there would not be a cache, that directory would be skipped anyway.

Updating the icon-cache can take a while (but should not take 15 minutes)

I installed SuSE 10.0 again yesterday and now making a disk-image so I can plug
it in in future more easily. 

Just remove the icon-theme.cache file from the locolor-directory and you won't
get the message.
You can take this as a test whether the gtk-update-icon-cache really is the
problem (I doubt that, but well - it is just software...)

I'd rather say it is the trigger-scripts that fail to run when called by yast.
But just skip the menu-integration package and see whether that causes yast to
hang as well.
If it doesn't hang, then there's something wrong with the menu-integration package.
Comment 10 lohmaier 2006-02-26 18:26:49 UTC
I was able to reproduce (need to check again whether this was just coincidence).

The problem is not th gtk-update-cache or similar, but the trigger that is meant
to avoid concurrent access to the rpm database by checking whether "pgrep rpm"
returns a process-id and sleeps for 2 seconds if it does.

The problem is that one defunct rpm process is sitting around, causing the
install-script to go into an endless loop.

Solution: get the process-ID of the install-script and kill it. Now the
installation can continue.
ps ax|grep /tmp/install
look for a line with
"<number>  [...] /bin/sh /tmp/install.<another_number>"
then run "kill <number>")
Comment 11 lohmaier 2006-02-26 19:42:26 UTC
tried again with same result.

when installing with yast, it for some reason creates a defunct rpm process that
leads to the loop in the trigger's install-script.

Not caused by the modifications to update the icon-cache. (happens with 2.0.1
packages as well).

Honestly I still wonder why people use yast to install rpms (it is so slow and
cumbersome to setup for non-installation media - it cannot even update the
directory itself, etc).. but anyway, here are the steps to reproduce on SuSE
10.0 (download-edition) based on a gnome-system:

0) copy the installation-files flat to a directory (Yast doesn't search in 
   subdirectories, so move the desktop-integration package to the same dir as 
   the other ones)
1) Run yast from the "system"-menu (supply root-password)
2) In the "Software" category choose "change installation source" (not sure 
   about the english label, but the badly translated german one is 
   "Installationsquelle wechseln")
3) Choose to add a local directory from the "Add" button and point to the path 
   with the RPMs created in step 0) (note that the entry-field doesn't support 
   "~" to specify the home-directory)
4) Leave the installation-Sources setup and switch to "Install or Deinstall 
   Software" ("Software installieren oder löschen")
5) Since the package-selection window doesn't allow multi-selection, search for
   "" (search only in package-name, not in description) then 
   choose to install all packages from the current selection from the  
   package-window's context-menu ("Alle in dieser Liste → Installieren")
6) Deselect the desktop-integraton packages (you may want to search for
   "*menus" with wildcard-match enabled)
7) Choose the button "Apply" from the lower right corner.

Yast will now install OOo (without the desktop-integration package which we will
install in a second step) and run some Update-scripts (useless and not needed
for OOo, but run nevertheless)

8) After the installation of the OOo packages is finished, choose to install 
   additional packages and verify in a terminal that you still have a clean
   environment (no defunct rpm-processes)
9) Choose to install the suse-menus package and click "apply"

The progress bar will reach 100% and then will stall. When checking in the
terminal, you'll notice a defunct rpm process.

10) Kill the install-script run by the trigger to allow the installation to

Since the trigger is not run, you'll have to create the symlink in /etc (and run
update-desktop-database) manually. Or better: Uninstall the menu-package and
install from commandline (where no problem occurs at all)
Comment 12 dennybeyer 2006-02-28 21:42:11 UTC
I tried rc4 on Suse9.3. Problem is still there. Yast freezes on installing
package core01 when trying to update from previous version.

@cloph: Yast kann sicherlich verbessert werden, aber bezogen auf Geschwindigkeit
ist immernoch OOo/SO (Negativ)Beispiel Nr.1! - UND: trotzdem gibt es immernoch
Leute die es verwenden :-)! - Dem hat die Entwicklung der letzten Jahre auch
nicht wirklich entgegengewirkt. Aber wenn die Prioritäten auch auf
Pinselfunktionen liegen und nicht wirklichen Einschränkungen ... Naja.
Comment 13 lohmaier 2006-03-01 02:19:40 UTC
@obr: issue 61569 is about problems of a missing pgrep on a RedHat based distro.
So when the trigger-script gets a rework (which is necessary I guess) these two
shall both be taken into account, thus I set it to the depends on field.
Comment 14 nospam4obr 2008-04-23 19:27:06 UTC
Issue 88334 finally allows us to abandon the RPM database query and thus the
check for a running rpm in the trigger script.
Comment 15 nospam4obr 2008-04-23 21:27:59 UTC
RPM database check has been removed in CWS native147.
Comment 16 nospam4obr 2008-04-28 10:21:12 UTC
To verify, make sure you have a RPM version 4 and run 

rpm -qp --triggers <menus-package>

This should not gives any instances of 'pgrep rpm' any more.
Comment 17 Olaf Felka 2008-04-28 11:37:22 UTC
OF: Looks good for me in cws native 147.
Comment 18 Olaf Felka 2008-10-22 11:58:02 UTC
OF: Looks good for me in OOO300_m9.