Terminal unresponsive
Does anyone know what causes this?
This doesn't seem to happen if the terminal is just sitting at a prompt.
9 Replies
I'm running Gentoo. The one place where it always happens is when I 'emerge sync' and Gentoo is updating the files around 50%. It will stick on that number. If I hit a key, then after a couple minutes it will finally come back and give me a prompt.
I have multiple Gentoo boxes (2 servers, 2 workstations, 2 laptops, 1 Linode), and they all take a while around the 50-51% mark, then picks up again.
Seems normal. Annoying, but normal.
strace -f'd the emerge –sync process and discovered that, around that time, it's heavily hitting /var/cache/edb/dep/usr/portage/kde-base-eclass.cpickle while it's processing /usr/portage/kde-base/*
cpickle is some sort of compressed or indexed database for Portage.
The one for kde-base is the largest single cpickle file; it's about 40x the typical cpickle size. It appears this is because of over 1,200 entries in kde-base… most others seems to have about 20-30 entries or so.
So it seems to be a combination of a) a lot of entries in the kde-base cpickle and b) a lot of I/O to it (though I don't think I remember running out of tokens for that on my Linode), c) a lot of entries = more time and CPU processing.
Bottom line: there's just a lot of stuff when it hits the KDE part of the Portage tree, so it takes a while to process all that stuff.
It's a lot faster doing it on my laptop with faster CPU than at Linode, so I think that ultimately, it's just that Linodes will simply take longer in this area and seem to "stall". I monitored I/O tokens usage throughout emerge --sync run on the Linode and don't remember running out or coming close.
But if you were already kinda low on I/O tokens when you ran the sync job, that could be enough to make things really slow.
On my Linode, I think the sync takes a few minutes to get past the 50-51% mark. On the laptop, about 30 seconds or so.
If I press a key, then after a few minutes it will print out all the rest of the info in one dump. So, it's not that it just slows down at this point, the terminal also stops updating at all.
I'm having a hard time explaining this, so to be clear: the terminal will not continue past the 50-52% mark EVER, unless I hit a key. It also sticks in other places, too, like when I 'tail -f' some log. I will notice that the tail isn't refreshing, hit a key, and then a few minutes later the log will continue. Likewise, if I ctrl-C the tail, it will still be a few minutes before it quits.
That is indeed interesting. I'm afraid I'm not seeing the same thing, but then again, I'm not actively tail'ing or watching when I do that stuff… I'll have to try a few experiments.
TERM = rxvt