Bug 444978 - telinit: Unable to send message: Connection refused
Summary: telinit: Unable to send message: Connection refused
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F9Blocker
TreeView+ depends on / blocked
 
Reported: 2008-05-02 15:12 UTC by Robert Scheck
Modified: 2008-05-05 18:50 UTC (History)
2 users (show)

Fixed In Version: 2.8-3
Clone Of:
Environment:
Last Closed: 2008-05-05 18:50:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Robert Scheck 2008-05-02 15:12:30 UTC
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 15:22:35 UTC
Is that in some chroot?  If not, it would be an upstart bug.

Comment 2 Robert Scheck 2008-05-02 15:45:41 UTC
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 15:51:56 UTC
... 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 16:02:41 UTC
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 16:33:26 UTC
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 17:51:30 UTC
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 17:56:31 UTC
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 15:06:44 UTC
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 18:50:32 UTC
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.