Port upgrade process STATE=wait

R

razixx

I'm having issues when trying to upgrade my installed ports.

Code: 
      For more information, and contact details about the security
      status of this software, see the following webpage: 
http://www.ruby-lang.org/en/
===>  Cleaning for ruby-1.8.7.302,1
--->  Cleaning out obsolete shared libraries
[Updating the pkgdb <format:bdb_btree> in /var/db/pkg ... - 645 packages found (-0 +1) . done]
--->  Upgrading 'kde4-icons-oxygen-4.5.3' to 'kde4-icons-oxygen-4.5.4' (x11-themes/kde4-icons-oxygen)
--->  Building '/usr/ports/x11-themes/kde4-icons-oxygen'
===>  Cleaning for kde4-icons-oxygen-4.5.4
===>  License check disabled, port has not defined LICENSE
===>  Extracting for kde4-icons-oxygen-4.5.4
=> SHA256 Checksum mismatch for KDE/oxygen-icons-4.5.4.tar.bz2.
===>  Refetch for 1 more times files: KDE/oxygen-icons-4.5.4.tar.bz2 
===>  License check disabled, port has not defined LICENSE
=> oxygen-icons-4.5.4.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/KDE.
=> Attempting to fetch from http://mirrors.isc.org/pub/kde/stable/4.5.4/src/.
oxygen-icons-4.5.4.tar.bz2                     65% of  237 MB  158 kBps 08m50s
It has seized at 65% and hasn't changed in 10 minutes. Currently I'm using portupgrade but experience the same behavior with portmaster as well.

top
Code: 
last pid: 91222;  load averages:  0.02,  0.07,  0.03                                          up 0+02:06:42  10:23:57
192 processes: 1 running, 191 sleeping
CPU:     % user,     % nice,     % system,     % interrupt,     % idle
Mem: 448M Active, 1103M Inact, 232M Wired, 708K Cache, 112M Buf, 1710M Free
Swap: 2048M Total, 2048M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
 1643 chris         3  76    0   287M 90320K kqread  0   2:50  1.17% kwin
 1563 root          1  45    0   827M 46224K select  2   1:17  0.78% Xorg
 1844 chris        12  46    0   167M   137M ucond   2   1:01  0.00% firefox-bin
 9271 root          1  76    0 65092K 58336K wait    3   0:48  0.00% ruby
 1802 chris         2  62    0   227M 67044K kqread  2   0:31  0.00% kdeinit4
 1809 chris         2  55    0   170M 72272K select  1   0:25  0.00% kdeinit4
 1648 chris         3  76    0   393M   101M select  2   0:11  0.00% kdeinit4
 1794 chris         6  70   19 54084K 38472K ucond   3   0:07  0.00% virtuoso-t
91160 chris         1  44    0 79316K 20364K select  2   0:05  0.00% npviewer.bin
 1833 chris         2  61    0   174M 70500K kqread  0   0:05  0.00% kmail
 1630 chris         3  76    0   151M 67392K select  1   0:03  0.00% kdeinit4
 1817 chris         3  70   19   100M 43268K ucond   0   0:03  0.00% nepomukservicestub
 1790 chris        12  63   19    98M 35484K select  0   0:02  0.00% nepomukservicestub
 1770 chris        21  52    0   137M 31840K sbwait  2   0:02  0.00% mysqld
 1805 chris         2  52    0   112M 49112K kqread  3   0:02  0.00% kopete
91056 root          1  44    0  5088K  2180K sbwait  3   0:02  0.00% fetch
 1555 root          1  44    0  3820K  1660K select  2   0:01  0.00% hald-addon-storage
 1797 chris         2  44    0   251M 84788K kqread  2   0:01  0.00% kdeinit4
  813 root          1  44    0  3452K  1120K select  3   0:01  0.00% moused
 1494 haldaemon     2  50    0 11504K  5312K piperd  2   0:01  0.00% hald
 1627 chris         1  53    0   103M 49096K select  3   0:01  0.00% kdeinit4
 1647 chris         4  44    0   113M 40932K ucond   1   0:01  0.00% knotify4
 1621 chris         1  44    0  4528K  2552K select  0   0:01  0.00% dbus-daemon
 1819 chris         2  70   19 86320K 31112K kqread  1   0:01  0.00% nepomukservicestub
 1807 chris         2  66    0   116M 45528K kqread  0   0:01  0.00% ktimetracker
 1780 chris         2  76    0 87420K 31920K select  0   0:00  0.00% akonadi_nepomuk_con
 1779 chris         1  44    0 83772K 29616K select  3   0:00  0.00% akonadi_maildispatc
 1777 chris         1  44    0 86364K 30756K select  0   0:00  0.00% akonadi_ical_resour
 1778 chris         1  44    0 83552K 29408K select  1   0:00  0.00% akonadi_maildir_res
 1776 chris         1  44    0 83640K 29108K select  3   0:00  0.00% akonadi_contacts_re
 1775 chris         1  44    0 83640K 29112K select  1   0:00  0.00% akonadi_contacts_re
 1835 chris         2  57    0   150M 64432K kqread  1   0:00  0.00% kdeinit4
 1829 chris         2  53    0   111M 42864K kqread  0   0:00  0.00% korgac
 1782 chris         1  44    0   139M 58760K select  0   0:00  0.00% kdeinit4
 1636 chris         1  44    0   141M 60052K select  0   0:00  0.00% kdeinit4
 1820 chris         2  76   19 83792K 30196K ucond   3   0:00  0.00% nepomukservicestub
 1818 chris         1  63   19 82104K 29896K select  3   0:00  0.00% nepomukservicestub

Any ideas of something I could try?
 
If the remote site stops sending, there's not much that can be done. After you get tired of waiting, stop portupgrade with ctrl-C, make a note of the ports that couldn't be upgraded, and try it again. You can rebuild the problem port by hand, either trying make fetch or manually downloading the distfile if necessary.
 
Thank you, I was not aware that it was because the remote site had stopped sending. I've just started using portupgrade, sending a ctrl-c stopped the current build and went on to the next. I was not aware of this behavior, portmaster would have stopped completely.
I like it.
 
A list of ports that were missed will be shown at the end. Save that, make sure to go back and upgrade all of them, then check dependencies with pkgdb -F. portupgrade should not continue if an upgrade of a port fails and something farther down the list depends on it... but it might.
 
Is this behavior common? It seems to happen to me quite regularly, but I only experience the above on my home PC.

If it is common, is there a way to manipulate the program so that if it does encounter this behavior and sits dormant for x number min, that it can skip and move on the the next port?
 
Looking at it again, I begin to wonder if something isn't going on with your computer. If the remote system stalls when sending the distfile, the kBps value should keep updating. But such stalls don't happen often. And I'd expect to see fetch in the top output, but it's not there.
 
You must log in or register to reply here.
Back
Top