पैकेज सूची पढ़ना हमेशा के लिए लेता है

25

मैं अपनी मशीन पर अपना सामान अपडेट करने की कोशिश कर रहा हूं, और ऐसा लगता है कि यह मेरी पैकेज सूची नहीं पढ़ सकता है। ऐसा लगता है कि हर बार जब मैं sudo apt-get install *something* && sudo apt-get updateपैकेज सूची को पढ़ने में अटक जाता हूं , तो यह पहले कोई समस्या नहीं रही है। यहाँ मेरा चश्मा और क्या है:

मेमोरी: 15.8 gb
प्रोसेसर: AMD Phenom (tm) II x4 965 प्रोसेसर x 4
ग्राफिक्स: AMD BARTS पर गैलियम 0.4
ओएस प्रकार: 32-बिट
इंटरनेट की गति :

command-line apt

— ड्रे
स्रोत

2

बस स्पष्ट कर रहे हैं ... आप निष्पादन के बारे में बात कर रहे हैं sudo apt-get update, सही है?

— जैक

2

इसमें Software Sources, देखें कि क्या आपके वर्तमान के बजाय, दूसरे सर्वर का चयन करने में मदद मिलती है।

इस समस्या के बारे में अधिक नहीं लिखने के लिए क्षमा करें। लेकिन यहाँ सौदा है! हर बार मैं एक sudo apt-get अपडेट चलाता हूं, sudo apt-get उन्नयन या 'sodu apt-get install कुछ ' यह अंतत: इसे मिलेगा, लेकिन यह 30 मिनट के साथ लेता है टीआई सूची को पढ़ते हैं। Ive सर्वर बदलने की कोशिश की, और वह मदद नहीं की।

— ड्रे

आपके कंप्यूटर और आपके इंटरनेट कनेक्शन की विशिष्टताएँ क्या हैं? नई जानकारी के साथ अपने प्रश्न को संपादित करें इसे टिप्पणियों में न जोड़ें ...

— अलवर

btw, आपके पास उस विनिर्देश पर 32-बिट क्यों है? इसका कोई मतलब नही बनता। मैं आपकी समस्या का पता नहीं लगा सकता, लेकिन आपने कितने अलग-अलग सर्वर आज़माए हैं? यह उत्तर मदद कर सकता है, askubuntu.com/a/44900/10698

— अलवर

22

मैंने वह भी देखा है।

मेरे पास कोई हल नहीं है, लेकिन मेरे पास वर्कअराउंड ( echo 3 | sudo tee /proc/sys/vm/drop_caches) और संभावित रूप से अधिक जानकारी है ताकि कोई भी किसी भी जांच को आगे ला सके।

यह कोई नेटवर्क समस्या नहीं है क्योंकि "पठन पैकेज सूची ..." पर , यह केवल फाइलों को पढ़ने में है /var/lib/apt/lists/। ए:

strace -tt -T -fo strace.log apt-get update

देता है:

16394 14:43:03.921130 open("/var/lib/apt/lists/gb.archive.ubuntu.com_ubuntu_dists_precise_main_binary-i386_Packages", O_RDONLY|O_LARGEFILE) = 7 <0.000012>
[...]
16394 14:43:03.995238 read(6, "-3.1ubuntu2)\nConflicts: linux86\n"..., 32444) = 32444 <0.000111>
16394 14:43:05.787187 read(6, "c (<< 1:14.b.4-dfsg), erlang-exa"..., 32239) = 32239 <0.000069>
16394 14:43:05.788025 read(6, ".deb\nSize: 42130\nMD5sum: c7de671"..., 31695) = 31695 <0.000068>
16394 14:43:05.870734 read(6, "5: 29c4b395a92bdc12932f151c3643a"..., 31607) = 31607 <0.000071>
16394 14:43:05.890862 read(6, "e-pack-af-base\nFilename: pool/ma"..., 32538) = 32538 <0.000070>
16394 14:43:05.891425 read(6, "buntu-usb-live, ubuntu-dvd-live,"..., 32090) = 32090 <0.000066>
16394 14:43:05.891960 read(6, "cd9755b03ac2c9b8251125c7b6618\nDe"..., 32195) = 32195 <0.000034>
16394 14:43:06.043001 read(6, "rg>\nArchitecture: all\nVersion: 2"..., 32535) = 32535 <0.000072>

देखें कि कैसे उन 8 readसिस्टम कॉल को 2 सेकंड से अधिक समय लगा, हालांकि प्रत्येक व्यक्तिगत कॉल में 1 एमएस से कम समय लगता है। दौड़ना time apt-get updateया देखना top, यह प्रक्रिया उन दो कॉल के बीच व्यस्त नहीं है। तो देरी क्यों?

फिर मैंने किया:

echo t > /proc/sysrq-trigger

कुछ समय और परिणाम में देखा kern.log:

 apt-get         D 00000000     0 16790  12706 0x00000000
  e8695d30 00000086 f7bd5e6c 00000000 f7bd5e44 f74a6580 c1990e00 c1990e00
  efe46efe 000042cb f7b9de00 e71a7230 f74a6580 c107e116 00000000 00000000
  044aa200 00000000 00000000 00000000 00000000 e8695d0c e8695d0c c1038de8
 Call Trace:
  [<c107e116>] ? enqueue_entity+0x186/0x220
  [<c1038de8>] ? default_spin_lock_flags+0x8/0x10
  [<c15e13bd>] ? _raw_spin_lock_irqsave+0x2d/0x40
  [<c15e0533>] schedule+0x23/0x60
  [<c15deecf>] schedule_timeout+0x12f/0x290
  [<c1075c38>] ? ttwu_do_activate.constprop.86+0x58/0x70
  [<c1055190>] ? usleep_range+0x40/0x40
  [<c15e0846>] io_schedule_timeout+0x86/0xd0
  [<c15cef7d>] balance_dirty_pages.isra.17+0x3f5/0x4b4
  [<c15e118d>] ? _raw_spin_lock+0xd/0x10
  [<c1180781>] ? __set_page_dirty_buffers+0x81/0xb0
  [<c110deb5>] ? set_page_dirty+0x55/0x60
  [<c11812c9>] ? __block_page_mkwrite+0xe9/0x170
  [<c110f3ae>] balance_dirty_pages_ratelimited_nr+0xde/0x100
  [<c1126f53>] do_wp_page+0x503/0x830
  [<c1128ef7>] handle_pte_fault+0x267/0x2c0
  [<c1129c62>] handle_mm_fault+0x1e2/0x280
  [<c15e4988>] do_page_fault+0x158/0x4c0
  [<c104e4dc>] ? irq_exit+0x5c/0xa0
  [<c15e22d0>] ? do_debug+0x180/0x180
  [<c15e4830>] ? vmalloc_fault+0x195/0x195
  [<c15e1c53>] error_code+0x67/0x6c

तो, यह निश्चित नहीं है कि इसका क्या मतलब है, लेकिन यह पृष्ठ दोषों से निपटने के बारे में दिखता है, इसलिए एक संभावित स्मृति प्रबंधन मुद्दे पर इंगित करता है।

मैंने तब कोशिश की:

echo 3 >/proc/sys/vm/drop_caches

और इससे समस्या दूर हो गई।

अब, यह एक कर्नेल मुद्दे की तरह दिखता है। इसलिए, मैंने नवीनतम कर्नेल (3.8 बैकपोर्ट) से अपडेट किया हैraring ) और यही वह जगह है जहां मैं हूं। यदि समस्या नए कर्नेल के साथ बनी रहती है तो अपडेट हो जाएगी।

संपादित करें

समस्या नए कर्नेल के साथ बनी रहती है, हालांकि उतनी बुरी नहीं है। और वही बात,

echo 3 | sudo tee /proc/sys/vm/drop_caches

थोड़ी देर के लिए समस्या को साफ करता है। मैंने केवल MSI लैपटॉप (उत्पाद का नाम: CR61 2M / CX61 2OC / CX61 2OD) पर देखा है।

दिसंबर 2015 को संपादित करें

के रूप में की पुष्टि की btrace aptitude/ apt-getसमय पर कुछ डिस्क I / O करने के लिए प्रकट होता है। यह एक अस्थायी फ़ाइल ( /var/cache/apt/pkgcache.bin.<random-chars>) मेमोरी में मिली हुई है, यही वजह है कि यह straceआउटपुट में प्रदर्शित नहीं होती है ।

अभी भी यह नहीं समझा सकता है कि यह केवल कुछ मशीनों पर ही क्यों होता है, क्यों छोड़ने से कैश में मदद मिलती है, क्यों 64 बिट में स्विच करने में मदद मिलती है।

यदि कोई इसे पुन: पेश कर सकता है, तो एक दिलचस्प परीक्षण यह देखने के लिए हो सकता है कि क्या यह तब भी होता है जब नीचे चल रहा है eatmydataया यदि एक रैमडिस्क चलती /var/cache/aptहै tmpfsया नहीं।

— स्टीफन चेज़लस
स्रोत

1

5 अप्रैल, 2014 को मैं पुष्टि कर सकता हूं कि समस्या अभी भी मौजूद है। पर परीक्षण किया गया: लिनक्स मिंट 16, 32 बिट, 64 बिट प्रोसेसर पर चलने वाला, लेनोवो W520, और: कुबंटु 12.10 32 बिट, फिर से 64 बिट हार्डवेयर पर चल रहा है, कस्टम निर्मित डेस्कटॉप। (और यहाँ सुझाया गया समाधान / वर्कअराउंड भी काम करता है :))

— Ferenc Deak

@ फ्रिट्ज़ोन, मुझे याद है कि समस्या कहीं और बताई गई है जहाँ लोग कह रहे थे कि 64 बिट OS पर स्विच करने से समस्या ठीक हो गई।

— स्टीफन चेजेलस

मैं 64 बिट OS पर भी वापस जाने की योजना बना रहा हूं। इससे पहले, डेस्कटॉप पर मेरे पास 12.10 का 64 बिट संस्करण था और इस तरह की कोई समस्या नहीं थी।

— फेरेनक डेक

समस्या अभी भी ubuntu 14.04 :-( पर मौजूद है। echo 3 के साथ आपके समाधान को drop_caches ने काम किया। यह क्लिपबोर्ड के साथ Inkscape के कुछ बहुत ही बगिया व्यवहार के बाद हुआ है जब नेटबिन के साथ गलत तरीके से टकरा रहा है जब उसने 100 बारबॉक्स या तो खोला है ... हालांकि Inkscape मारा गया था, इसने सिस्टम में कुछ गड़बड़ी छोड़ दी, जो पूरी तरह से धीमा हो गया, पैकेजों को पढ़ना।

— पालो

मैं इसे कुछ समय के लिए भी देखता हूं, और वर्कअराउंड मेरे लिए काम नहीं करता है। यह एक 64 बिट ऑपरेटिंग सिस्टम है यहाँ, i7 और 8G रैम वाले सैमसंग लैपटॉप पर। केवल एक रिबूट समस्या को दूर कर देता है। अजीब।

— रमनो

5

Http://antti-juhani.kaijanaho.fi/newblog/archives/521 की सलाह ने इसे विभिन्न कंप्यूटरों पर मेरे लिए कई बार उतारा:

sudo dpkg --clear-avail
sudo sync-available

(ब्लॉग को भी sudo dpkg --forget-old-unavail2 चरणों के बीच अनुशंसित किया गया था, लेकिन जाहिर है कि यह अब समाप्त हो गया है और इसकी आवश्यकता नहीं है।)

— बेनी चेर्नियाव्स्की-पास्किन
स्रोत

4

उनके नक़्शे - कदम पर चलिए:

कैश साफ़ करें:
```
sudo apt-get clean
```
ले जाएँ sources.listतो aptइसका उपयोग नहीं कर सकते हैं:
```
mv /etc/apt/sources.list /etc/apt/sources.list1 && sudo apt-get update
```
इसे वापस ले जाएं फिर अपडेट करें:
```
mv /etc/apt/sources.list1 /etc/apt/sources.list && sudo apt-get update 
```

इसके अलावा किसी भी पीपीए और स्रोत लाइनों को जांचें और हटाएं जिनकी आपको आवश्यकता नहीं है।

— रूपर्ट
स्रोत

1

मेरे सिस्टम पर, कारण LANGUAGE=पर्यावरण चर में एक गलत मूल्य था । इसे मानों को धारण करना चाहिए en:fr:de, जैसे en_US.UTF-8,sl_SI.UTF-8:

root@fik:~
# locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8,sl_SI.UTF-8
LC_CTYPE=sl_SI.UTF-8
LC_NUMERIC=sl_SI.UTF-8
LC_TIME=sl_SI.UTF-8
LC_COLLATE=sl_SI.UTF-8
LC_MONETARY=sl_SI.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=sl_SI.UTF-8
LC_NAME=sl_SI.UTF-8
LC_ADDRESS=sl_SI.UTF-8
LC_TELEPHONE=sl_SI.UTF-8
LC_MEASUREMENT=sl_SI.UTF-8
LC_IDENTIFICATION=sl_SI.UTF-8
LC_ALL=

जब (के माध्यम से strace) भाग गया , apt-get updateकमांड कॉल पर क्लोन करता है read()। इसे निष्पादित करने में उम्र लगती है, और एक CPU कोर के सभी उपलब्ध चक्रों को खाता है:

root@fik:~
# strace apt-get update
[snip]
read(5, "form, hardware::opengl, implemen"..., 32146) = 32146
read(5, " Maintainers <pkg-bluetooth-main"..., 32658) = 32658
read(5, ": 17569748\nMD5sum: 9c20d52f9a0d5"..., 32200) = 32200
brk(0x55ac79212000)                     = 0x55ac79212000
read(5, "scription-md5: ca1156b27bec24d4c"..., 32469) = 32469
read(5, " Boost.Math Library\nMulti-Arch: "..., 32477) = 32477
read(5, "epends: libc6 (>= 2.4), lsb-base"..., 32648) = 32648
^C--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
strace: Process 18452 detached

यदि मैं LANGUAGE=एक सही मान पर सेट करता हूं (जैसे en), तो सब कुछ फिर से सामान्य हो जाता है:

root@fik:~
# export LANGUAGE=en

root@fik:~
# locale
LANG=en_US.UTF-8
LANGUAGE=en
LC_CTYPE=sl_SI.UTF-8
LC_NUMERIC=sl_SI.UTF-8
LC_TIME=sl_SI.UTF-8
LC_COLLATE=sl_SI.UTF-8
LC_MONETARY=sl_SI.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=sl_SI.UTF-8
LC_NAME=sl_SI.UTF-8
LC_ADDRESS=sl_SI.UTF-8
LC_TELEPHONE=sl_SI.UTF-8
LC_MEASUREMENT=sl_SI.UTF-8
LC_IDENTIFICATION=sl_SI.UTF-8
LC_ALL=

root@fik:~
# apt-get update
Hit:1 http://ftp.at.debian.org/debian experimental InRelease
Ign:3 http://ftp.at.debian.org/debian jessie InRelease                                                      
Hit:4 http://ftp.at.debian.org/debian jessie-updates InRelease  
Hit:5 http://ftp.at.debian.org/debian jessie-backports InRelease                                                                             
Hit:6 http://ftp.at.debian.org/debian sid InRelease                                                                    
Hit:7 http://ftp.at.debian.org/debian stretch InRelease                               
Hit:8 http://ftp.at.debian.org/debian stretch-updates InRelease                                             
Hit:9 http://ftp.at.debian.org/debian jessie Release                                  
Hit:2 http://screenshots.getdeb.net xenial-getdeb InRelease                           
Hit:10 http://security.debian.org jessie/updates InRelease      
Hit:11 http://security.debian.org stretch/updates InRelease
Reading package lists... Done

— shkitch
स्रोत

ओह, और निश्चित रूप से मैंने कुछ साल पहले खुद को गलत मान दिया था। मजेदार रूप से पर्याप्त, उपयुक्त कल तक त्रुटिपूर्ण रूप से काम कर रहा था, II apt-get उन्नयन के बाद प्रणाली (डेबियन साइड)।

— शिखिच

मैंने अचानक डेबियन जेसी की 32-बिट की स्थापना पर इसका सामना किया है जो वर्षों (दशकों से) काम कर रहा है। मशीन कॉन्फ़िगरेशन में कुछ भी नहीं बदला, लेकिन यह अचानक होने लगा। मेरे पास कुछ भी नहीं है, हालांकि कुछ भी नहीं है। इसे "en" पर सेट करना या C का उपयोग सभी LC_ * लोकल वैरिएबल के लिए अभी तक करने में मदद नहीं किया।

— ब्रैड स्पेंसर