Bug 444978 - telinit: Unable to send message: Connection refused
telinit: Unable to send message: Connection refused
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
All Linux
low Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F9Blocker
  Show dependency treegraph
 
Reported: 2008-05-02 11:12 EDT by Robert Scheck
Modified: 2008-05-05 14:50 EDT (History)
2 users (show)

See Also:
Fixed In Version: 2.8-3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-05 14:50:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2008-05-02 11:12:30 EDT
Description of problem:
While upgrading von glibc-2.8-1 to glibc-2.8-2 on i686, I'm seeing the 
following, which is broken/has to be fixed ASAP:

tux:~ # rpm -Uvh i686/glibc-2.8-2.i686.rpm i386/glibc-common-2.8-2.i386.rpm 
i386/glibc-devel-2.8-2.i386.rpm i386/glibc-headers-2.8-2.i386.rpm
Preparing...                ########################################### [100%]
   1:glibc-common           ########################################### [ 25%]
   2:glibc                  ########################################### [ 50%]
telinit: Unable to send message: Connection refused
/usr/sbin/glibc_post_upgrade: While trying to execute /sbin/telinit child 
exited with exit code 1
error: %post(glibc-2.8-2.i686) scriptlet failed, exit status 1
   3:glibc-headers          ########################################### [ 75%]
   4:glibc-devel            ########################################### [100%]
tux:~ #

Version-Release number of selected component (if applicable):
glibc-2.8-1.i686
glibc-2.8-2.i686

How reproducible:
Everytime, see above.

Actual results:
telinit: Unable to send message: Connection refused

Expected results:
Working RPM package installation without failing scriptlet.

Additional info:
I'm marking this bug report as blocker bug for F9 because glibc-2.8-2 is tagged 
for F9 final.
Comment 1 Jakub Jelinek 2008-05-02 11:22:35 EDT
Is that in some chroot?  If not, it would be an upstart bug.
Comment 2 Robert Scheck 2008-05-02 11:45:41 EDT
No chroot. But you should know, that I've upgraded from sysvinit to upstart 
where the installation of glibc-2.8-1 happend with sysvinit while upgrading 
from 2.8-1 to 2.8-2 was done after upstart was installed, but no reboot in the
meantime. 

This has to be catched anyway, because otherwise upgrading from Fedora 8 to 9
will get a real problem for the users.
Comment 3 Bill Nottingham 2008-05-02 11:51:56 EDT
... the entirety of the issue here is that a couple of libraries will be used
slightly longer (until a reboot). In this particular case, the entire /sbin/init
binary is no longer in use - you can't tell it to re-init properly.

I'm not seeing how this would have a bad impact.
Comment 4 Robert Scheck 2008-05-02 12:02:41 EDT
Bad impact is, that my rpmdb now thinks, that glibc-2.8-1 AND glibc-2.8-2 are 
installed because of the failed scriptlet. So can we catch the error and make 
exiting /usr/sbin/glibc_post_upgrade without an error exit/return code?
Comment 5 Jakub Jelinek 2008-05-02 12:33:26 EDT
The reason why glibc %post does telinit u is to avoid unclean shutdown - if the
old init is still running, it will still reference already unlinked libc.so.6,
ld.so etc. and won't umount cleanly.  Even without any glibc upgrade this is
going to be a problem in sysvinit -> upstart upgrades.
Comment 6 Robert Scheck 2008-05-02 13:51:30 EDT
Well, a good reason to leave Ubuntu Ubuntu and just use Fedora sysvinit again ;-)

And now being more serious: How to solve this issue best? Ideas? Suggestions?
Comment 7 Bill Nottingham 2008-05-02 13:56:31 EDT
It's sort of like static dev -> udev; it's not something that lends itself to a
practical live upgrade. You can't rexec sysvinit init into upstart init and pass
the state in a reasonable manner; so glibc should probably just ignore the failure.
Comment 8 Will Woods 2008-05-05 11:06:44 EDT
There's a fix for this in glibc-2.8-3 - build available here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=48111
Comment 9 Robert Scheck 2008-05-05 14:50:32 EDT
Yes, solves the problem for me. Thank you, closing now.

Note You need to log in before you can comment on or make changes to this bug.