Muon hangs when using etckeeper

[Christian Schürer-Waldheim]

I'm using etckeeper, which works great together with apt and aptitude. But when running an installation or update with muon, muon hangs when the etckeeper process is invoked.

[mebuntu (salsa-temps)]

I have found that Muon has hung a few times over the past couple of days. I have done an installation just now and it is at 99% "running post-installation trigger tex-common". Not sure if this is the same as your report but I'm sure the gurus will be able to tell.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[m4v (m4v)]

@mebuntu, It would be helpful if you could tell if you're using etckeeper or not.

[Conner Lee (connerleecml)]

i am not using etckeeper. but it hangs at running post-installation trigger libcbin.

[Conner Lee (connerleecml)]

for me

[Conner Lee (connerleecml)]

also i got told i need to restart to finish the update process as a notification. i click and for restart but then it says muon has cancelled login.

[Conner Lee (connerleecml)]

logout*

[Jose Marquez (ubuntu-hackwater)]

I can confirm a hung qaptworker process when using Muon and Etckeeper (git backend; don't know if that matters). My process list shows Etckeeper trying to run its post install hooks:

root 21547 0.0 0.3 209940 12076 pts/1 S+ 09:38 0:00 /usr/bin/qaptworker
root 21548 0.0 0.0 4264 580 pts/1 S+ 09:38 0:00 sh -c if [ -x /usr/bin/etckeeper ]; then etckeeper post-install; fi
root 21549 0.0 0.0 4264 584 pts/1 S+ 09:38 0:00 /bin/sh /usr/bin/etckeeper post-install
root 21552 0.0 0.0 4264 580 pts/1 S+ 09:38 0:00 /bin/sh /etc/etckeeper/post-install.d/50vcs-commit
root 21559 0.0 0.0 4264 684 pts/1 S+ 09:38 0:00 /bin/sh /usr/bin/etckeeper commit --stdin
root 21580 0.0 0.0 4264 684 pts/1 S+ 09:38 0:00 /bin/sh /etc/etckeeper/commit.d/50vcs-commit --stdin
root 21588 0.0 0.0 21256 3148 pts/1 S+ 09:38 0:00 git commit -F /tmp/etckeeper-git.3LKSQ15yW7

Although the commit appears to not have completed, running git log on the /etc directory shows that it has actually done so.

[Christian Schürer-Waldheim (quincunx)]

I guess this is related to: #872553, #791839

[Michael Gliwinski (tzeentch-gm)]

@Christian: I don't think so, these were apparently fixed in etckeeper 0.56ubuntu2.1 which is the version I'm running and I still see the problem.

I've actually been able to trace the problem to $VCS subprocess launched by etckeeper hanging when trying to write to stdout/stderr. What is happening in my case is: /etc/etckeeper/commit.d/50vcs-commit is trying to determine the username and runs bzr whoami, this process hangs and strace shows:

Process 7327 attached - interrupt to quit
write(2, "bzr: ERROR: Unable to determine "..., 139

This would also happen if it got through to actually running $VCS commit, I think. I haven't checked yet what qaptworker does with stdout/stderr of launched sub-processes, but I did notice it allocates a pty.

[Jonathan Thomas (echidnaman)]

This is probably another instance of the problem seen in bug 855793, pointing the blame back to dpkg. (The pty code didn't change at all between 11.04 and 11.10, and packagekit is seeing the same issue.)

[ilia (ilia)]

Today I started an update of many packages and muon hung on 71%. This is not related to etckeeper, but looks related to the pseudoterminal output, similarly to comment #10. The actually hung process is /bin/sh (dash), trying to write to stdout.

$ ps -e f #only a relevant part
20736 ? Sl 1:04 /usr/bin/muon-updater
20794 ? Sl 0:16 /usr/bin/qaptworker
20902 pts/22 Ss+ 0:00 \_ /usr/bin/qaptworker
26578 pts/23 Ss+ 0:00 \_ /usr/bin/dpkg --status-fd 47 --configure libudev0 libcurl3 libcurl4-openssl-dev libcurl3:i386 libcurl3-gnutls libgudev-1.0-0 li
 4575 pts/23 S+ 0:00 \_ /bin/sh /var/lib/dpkg/info/initramfs-tools.postinst triggered update-initramfs
 4576 pts/23 S+ 0:00 \_ /bin/sh /usr/sbin/update-initramfs -u
 4589 pts/23 S+ 0:00 \_ /bin/sh /usr/sbin/mkinitramfs -o /boot/initrd.img-3.0.0-15-generic.new 3.0.0-15-generic
10174 pts/23 S+ 0:00 \_ /bin/sh /usr/share/initramfs-tools/hooks/framebuffer

$ sudo strace -p 10174
Process 10174 attached - interrupt to quit
write(1, "\n", 1
^C <unfinished ...>
Process 10174 detached

$ sudo lsof -p 10174
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
framebuff 10174 root cwd DIR 253,1 4096 2 /
framebuff 10174 root rtd DIR 253,1 4096 2 /
framebuff 10174 root txt REG 253,1 109768 524297 /bin/dash
framebuff 10174 root mem REG 253,1 1677624 1061598 /lib/x86_64-linux-gnu/libc-2.13.so
framebuff 10174 root mem REG 253,1 141088 1061605 /lib/x86_64-linux-gnu/ld-2.13.so
framebuff 10174 root 0u CHR 136,23 0t0 26 /dev/pts/23
framebuff 10174 root 1u CHR 136,23 0t0 26 /dev/pts/23
framebuff 10174 root 2u CHR 136,23 0t0 26 /dev/pts/23
framebuff 10174 root 10r REG 253,1 492 395156 /usr/share/initramfs-tools/hooks/framebuffer
framebuff 10174 root 11u CHR 136,23 0t0 26 /dev/pts/23
framebuff 10174 root 45w REG 253,2 39619 57 /var/log/apt/history.log

$ sudo lsof /dev/pts/23
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
initramfs 4575 root 0u CHR 136,23 0t0 26 /dev/pts/23
initramfs 4575 root 1u CHR 136,23 0t0 26 /dev/pts/23
initramfs 4575 root 2u CHR 136,23 0t0 26 /dev/pts/23
update-in 4576 root 0u CHR 136,23 0t0 26 /dev/pts/23
update-in 4576 root 1u CHR 136,23 0t0 26 /dev/pts/23
update-in 4576 root 2u CHR 136,23 0t0 26 /dev/pts/23
mkinitram 4589 root 0u CHR 136,23 0t0 26 /dev/pts/23
mkinitram 4589 root 1u CHR 136,23 0t0 26 /dev/pts/23
mkinitram 4589 root 2u CHR 136,23 0t0 26 /dev/pts/23
framebuff 10174 root 0u CHR 136,23 0t0 26 /dev/pts/23
framebuff 10174 root 1u CHR 136,23 0t0 26 /dev/pts/23
framebuff 10174 root 2u CHR 136,23 0t0...

[Jonathan Thomas (echidnaman)]

Fix committed upstream for QApt 1.2.3 and 1.3. Thanks for the patch

[Launchpad Janitor (janitor)]

This bug was fixed in the package qapt - 1.2.95-0ubuntu1

---------------
qapt (1.2.95-0ubuntu1) precise; urgency=low

  * New upstream release candidate (LP: #840306)
 -- Jonathan Thomas <email address hidden> Sun, 29 Jan 2012 10:39:17 -0500

[Brett Keller (blkeller)]

This fix has been packaged for precise, but not for oneiric. The oneiric repositories still have qapt and muon 1.2.1, which still leaves a fresh Kubuntu 11.10 installation ready to break upon the first round of updates via Muon Updater.

Since this breaks basic package management functionality for the average stable release user who is just doing what the OS is prompting him/her to do, I would like to request a minimum version upgrade from 1.2.1 to 1.2.3 in the oneiric repositories, please.

I have tested a fresh Kubuntu 11.10 installation on a spare laptop, and updating muon and qapt to 1.2.3 from Jonathan Thomas' QApt PPA before running the first round of regular updates fixed this bug for me. Without the PPA upgrade to 1.2.3, the first Full Update right after installation will attempt to install/upgrade 356 packages and get hung up at 49% during "Committing Changes".

Steps to reproduce restoration of expected update behavior:
1. Perform a fresh installation of Kubuntu 11.10 -- my tests were run on the i386 version
2. During installation, do not check the "Install updates" option
3. After installer completes, reboot, login, and ignore notification from Muon Updater
4. Open Muon Package Manager
5. Verify software version in "About Muon Package Manager" = 1.2.1
6. Configure Software Sources -> Other Software -> Add... "ppa:echidnaman/qapt"
7. Close and re-open Muon Package Manager -- this seems to be necessary to force the Filters list to recognize the newly added PPA even though "Check For Updates" has been performed (separate bug, maybe?)
8. Under "Filter:" choose "By Origin" and select "QApt PPA"
9. Select all packages in this filtered list that have the status "Upgradeable" and mark them for upgrade -- for me, this included 10 packages
10. Apply changes
11. Close and re-open Muon Package Manager
12. Verify software version in "About Muon Package Manager" = 1.2.3
13. Check For Updates, Full Upgrade, Apply Changes

These steps resulted in the same 356 packages as before getting installed/upgraded, except the update procedure completed to 100% without any hang ups. I have yet to notice any negative impact from installing version 1.2.3 of muon & qapt, only the positive impact of the bugfix.

Thanks.