On Sun, May 28, 2006 at 06:35:24AM -0700, Michael Nelson wrote:
Aaarrggghhh. I should have looked there earlier, I had assumed this was something I had screwed up, but "Bug 147966 - acroread takes long time to start" looks like the same issue:
https://bugzilla.novell.com/show_bug.cgi?id=147966
I'll play with the workarounds noted in that as yet unfixed CRITICAL bug.
OK, I'm a dummy. Somewhere along the line I had installed Adobe's AdobeReader package. The startup script for that is /usr/bin/acroread. The startup script for the SuSE supplied one is /usr/X11R6/bin/acroread, which is *after* /usr/bin in my $PATH. So all this time I have been running and troubleshooting the Adobe version instead of the SuSE version. The SuSE version does have a fix in it for bug 147966, and it starts MUCH faster. I do still see some inefficiencies in the tracelog though, even with the SuSE startup script. For instance, initially the script finds libc.so.6 right away in /lib, which is where it is and where a program should be looking for it. But after a while it loses its mind and does this: 3264 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) <0.000020> 3264 open("/opt/gnome/lib/tls/i686/tm/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) <0.00 0041> 3264 open("/opt/gnome/lib/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) <0.00001 7> 3264 open("/opt/gnome/lib/tls/tm/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000016> 3264 open("/opt/gnome/lib/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000016> 3264 open("/opt/gnome/lib/i686/tm/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000023
3264 open("/opt/gnome/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000016> 3264 open("/opt/gnome/lib/tm/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000021> 3264 open("/opt/gnome/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000024> 3264 open("/lib/tls/i686/tm/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000027> 3264 open("/lib/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000014> 3264 open("/lib/tls/tm/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000014> 3264 open("/lib/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000014> 3264 open("/lib/i686/tm/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000020> 3264 open("/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000015> 3264 open("/lib/tm/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000021> 3264 open("/lib/libc.so.6", O_RDONLY) = 3 <0.000020> ...then, for the rest of the trace log it follows that same screwy pattern every time it wants to access libc.so.6, and that *has* to be slowing things down. Michael -- San Francisco, CA