Description of problem:
running up2date from 8.0.92 to 8.0.93
most updates went in alpha order. When daemons were restarted ( I saw cups)
they would fail with:
Jan 21 15:03:05 office15 cups: cupsd shutdown succeeded
Jan 21 15:03:07 office15 cupsd: cupsd: error while loading shared libraries:
libssl.so.4: cannot open shared object file: No such file or directory
Jan 21 15:03:07 office15 cups: cupsd startup failed
This is because openssl gets updated later.
/sbin/init 1 ; /sbin/init 5 will fix all , but ...
looks like a possible packaging bug with cups (or possible openssl),
I did this on a desktop machine so cups was the only affected daemon running
that came before the openssl update. If I had been running apache , openldap,
etc. they would probably have not restarted also. Hence putting it under up2date.
Adrian: what kind of packaging problem am I looking for? cups requires
libssl.so.4 like it should.
Hard to say. Maybe cups needs a PreReq on openssl?
Looking at the scripts, I'm not exactly sure why the
init scripts would be getting tickled on an upgrade
either, unless `alternatives` is somehow doing it.
Nothing else in the script's stands out as something
that should be troubleprone. I'll poke jbj and see
what his thought is.
Hmmm, this might be a skipped (this is a feature, not a bug)
ldconfig that has not regenerated the symlink for a daemon
In order to tell, I'd need the ordered list of packages
for this up2date run so that I could see whether ldconfig
was run between openssl and cups package install. I'd need
to know the several packages before openssl was installed as well.
Look in /var/log/up2date for a line similar to:
[Tue Jan 21 20:51:37 2003] up2date installing packages: ['kdeadmin-3.1-0.4',
'kdeutils-3.1-0.3', 'kdelibs-3.1-0.11', 'kdebase-3.1-0.14', 'ope
nssl-0.9.7-3', 'openssl096b-0.9.6b-1', 'lm_sensors-2.6.5-3',
(except with the right date, and the packages you updated). This
should get some of the info jbj is looking for.
I'll add a 'rpm -qa --last' if you want, but basically it was:
[A-Z]* in alpha order
[a-z]* in alpha order
As if the "depends on this and that" step was done but ignored
ldconfig running or not wouldn't have mattered as /lib/libssl.so.0.9.7 was not
installed on the hard drive yet to symlink libssl.so.4 from.
yes? no? maybe?
Created attachment 89536 [details]
output from up2date
Hmmm, I need the ordering info. Can you append
rpm -qa --last
here too? Thanks.
Created attachment 89649 [details]
output of rpm -qa --last
output of rpm -qa --last
up2date was hosed ( no versions showed up)
I tried rpm -Fvh redhat-release-8.0.93-2...
rpm --rebuilddb (hung)
rpm --rebuilddb (go get coffee)
OK, this is not a missing ldconfig problem afaict.
BTW, all that's needed is
rm -f /var/lib/rpm/__db*
you don't *have* to do --rebuilddb.
I suspect that your hangs are from doing "kill -9" too.
But, if you find the coffee pot empty, --rebuilddb -vv
will give you progress message sto watch
CUPS clearly has the dependency listed for openssl. I don't see how this can be
a packaging problem, unless I'm missing something.