Bug 46987
| Summary: | Неправильный расчёт времени обновлении индексов при небольшой дельте | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Branch p11 | Reporter: | ruslandh <ruslandh> | ||||||
| Component: | update-kernel | Assignee: | Vitaly Chikunov <vt> | ||||||
| Status: | REOPENED --- | QA Contact: | qa-p11 <qa-p11> | ||||||
| Severity: | normal | ||||||||
| Priority: | P5 | CC: | amakeenk, boyarsh, evg, greystekl0, ila.nazarov, iv, lav, mike, ruslandh, vt | ||||||
| Version: | unspecified | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Attachments: |
|
||||||||
Created attachment 13888 [details]
Выдача sh -x update-kernel
Разница во времени создания индексов единица (как я понимаю 1 секунда), а выдает что индексы устарели на 251 день, что приводит в транс ;-)
Не понятно как получилась эта секунда, но 251 день это слишком.
Это в p10, но возможно и в Сизифе. Если в Сизифе этого нет, то перевешу на p10.
PS Как получилась разница в одну секунду тоже не понятно, но ...
rpm -qa | grep update-kernel update-kernel-1.8-alt1.noarch К сожалению у меня это не воспроизводится. Возможно ли что в системе не точно идут часы? Мне уже присылали подобный баг-репорт, но там дело решилось заменой батарейки. (In reply to ruslandh from comment #1) > Выдача sh -x update-kernel Простите за любопытсво, я почитал. $ grep now update-kernel.log + now=1689822245 $ TZ=Europe/Moscow date --date=@1689822245 Thu Jul 20 06:04:05 AM MSK 2023 update-kernel вы вызывали сегодня примерно в 6:04 по Москве. Именно с этим временем сравнивается время создания индексов. $ grep ' t=' update-kernel.log + t=1668090813 + t=1668090812 + t=1668090815 + t=1668090812 + t=1668090815 + t=1668090814 $ TZ=Europe/Moscow date --date=@1668090812 Thu Nov 10 05:33:32 PM MSK 2022 По данным команды stat, последние изменения в файлы индексов происходили 10 ноября прошлого года. Дальше update-kernel всё чётко посчитал. Дальше возможны три варианта: * вы правда давно не обновляли индексы. так бывает, не нужно этого стесняться =) * между apt-get update и update-kernel у Вас проснулась синхронизация времени и выставила нормальное время. Кто у Вас этим занимается, chrony? Посмотрите в его логи. * у Вас очень интересная файловая система. Можете показать вывод `stat /var/lib/apt/lists/*`? И заодно что там за раздел и с какими опциями он смонтирован. (Ответ для Ivan A. Melnikov на комментарий #5) > (In reply to ruslandh from comment #1) > > Выдача sh -x update-kernel > > Простите за любопытсво, я почитал. > > $ grep now update-kernel.log > + now=1689822245 > $ TZ=Europe/Moscow date --date=@1689822245 > Thu Jul 20 06:04:05 AM MSK 2023 > > update-kernel вы вызывали сегодня примерно в 6:04 по Москве. Именно с этим > временем сравнивается время создания индексов. > > $ grep ' t=' update-kernel.log > + t=1668090813 > + t=1668090812 > + t=1668090815 > + t=1668090812 > + t=1668090815 > + t=1668090814 > $ TZ=Europe/Moscow date --date=@1668090812 > Thu Nov 10 05:33:32 PM MSK 2022 > > По данным команды stat, последние изменения в файлы индексов происходили 10 > ноября прошлого года. Дальше update-kernel всё чётко посчитал. > > Дальше возможны три варианта: > * вы правда давно не обновляли индексы. так бывает, не нужно этого > стесняться =) > * между apt-get update и update-kernel у Вас проснулась синхронизация > времени и выставила нормальное время. Кто у Вас этим занимается, chrony? > Посмотрите в его логи. > * у Вас очень интересная файловая система. > > Можете показать вывод `stat /var/lib/apt/lists/*`? И заодно что там за > раздел и с какими опциями он смонтирован. Вечером посмотрю. Я это утром сделал и другими делами занялся. 1. Индексы обновлял 2. Это маловероятно, так как это у меня это воспроизвелось не один раз (говорил no, потом apt-get update) - первое, что пришло в голову. 3. Вечером сделаю. $ cd /var/lib/apt/lists/ $ df -h . Файловая система Размер Использовано Дост Использовано% Cмонтировано в /dev/sda5 205G 124G 71G 64% / $ findmnt | grep sda5 / /dev/sda5 ext4 rw,noatime $ cat /etc/fstab # /dev/sda5 ... UUID=e940e8d4-5380-4515-bf4f-de664e867538 / ext4 defaults,discard,noatime 1 1 .... Created attachment 13892 [details]
stat /var/lib/apt/lists/* > list_stat.log
discard виноват ? Вернее noatime "Параметр noatime полностью отключает запись времени доступа к файлу. Большинство программ не используют это поле. Но бывают и редкие исключения — например, Mutt полагается на его значение. Для mutt вы можете использовать параметр relatime." Всё ясно ;-) touch /var/lib/apt/lists/* всё лечит ;-) Если только его в apt-get update встроить ;-) Спасибо. А можно посмотреть вывод apt-config dump | grep Dir ? ]$ apt-config dump | grep Dir Dir "/"; Dir::State "var/lib/apt/"; Dir::State::lists "/tmp/.apt-cache/lists/"; Dir::State::cdroms "cdroms.list"; Dir::State::prefetch "prefetch"; Dir::Cache "/tmp/.apt-cache"; Dir::Cache::archives "archives/"; Dir::Cache::srcpkgcache "srcpkgcache.bin"; Dir::Cache::pkgcache "pkgcache.bin"; Dir::Etc "etc/apt/"; Dir::Etc::sourcelist "sources.list"; Dir::Etc::sourceparts "sources.list.d"; Dir::Etc::vendorlist "vendors.list"; Dir::Etc::vendorparts "vendors.list.d"; Dir::Etc::main "apt.conf"; Dir::Etc::parts "apt.conf.d"; Dir::Etc::preferences "preferences"; Dir::Etc::preferencesparts "preferences.d"; Dir::Etc::pkgpriorities "pkgpriorities"; Dir::Etc::translatelist "translate.list"; Dir::Etc::translateparts "translate.list.d"; Dir::Bin ""; Dir::Bin::methods "/usr/lib64/apt/methods"; Dir::Bin::rpm "/bin/rpm"; Dir::Bin::scripts "/usr/share/apt/scripts"; Dir::Ignore-Files-Silently ""; Dir::Ignore-Files-Silently:: "~$"; Dir::Ignore-Files-Silently:: "\.disabled$"; Dir::Ignore-Files-Silently:: "\.bak$"; Dir::Ignore-Files-Silently:: "\.dpkg-[a-z]+$"; Dir::Ignore-Files-Silently:: "\.ucf-[a-z]+$"; Dir::Ignore-Files-Silently:: "\.save$"; Dir::Ignore-Files-Silently:: "\.orig$"; Dir::Ignore-Files-Silently:: "\.distUpgrade$"; Dir::Locale "/usr/share/locale"; Спасибо большое. А как и почему задан параметр Dir::State::lists? Так, я задумался сам ;-) Это может быть связано, что обновляюсь не напрямую, а через локальное зеркало ? rpm [p10] file:/mnt/Arhiv/Branch-p10/ x86_64 classic gostcrypto debuginfo rpm [p10] file:/mnt/Arhiv/Branch-p10/ x86_64-i586 classic rpm [p10] file:/mnt/Arhiv/Branch-p10/ noarch classic Как фиксить уже понятно, просто интересно как система стала такой, чтоб понять на сколько это часто происходит. Это значение Dir::State::lists прописано вручную в конфигах /etc/apt (давно?) или какой-то пакет или скрипт это устанавливает? (In reply to Vitaly Chikunov from comment #17) > какой-то пакет или скрипт > это устанавливает? Похоже на работу apt-conf-tmp-cache. (In reply to Ivan A. Melnikov from comment #18) > (In reply to Vitaly Chikunov from comment #17) > > какой-то пакет или скрипт > > это устанавливает? > > Похоже на работу apt-conf-tmp-cache. Большое спасибо за информацию! (ps. Погуглил и не нашел зачем нужен этот пакет.) update-kernel-1.11-alt1 -> sisyphus: Mon Jul 24 2023 Vitaly Chikunov <vt@altlinux> 1.11-alt1 - Fix incorrect apt database oldness message when apt-conf-tmp-cache is used (ALT#46987). Starterkit gnome p11, образ от 12 декабря, использовалась автоматическая разбивка BTRFS При отсутствии обновлений в репозитории, update-kernel выводит предупреждение "ATTENTION: Your APT database is 3 days old. Please run 'apt-get update'!", хотя буквально перед этой командой выполнялось apt-get update Только что воспроизвелось на ALT Workstation K 11.0ALPHA: ``` # apt-get update && update-kernel Получено: 1 http://ftp.altlinux.org p11/branch/x86_64 release [4210B] Получено: 2 http://ftp.altlinux.org p11/branch/x86_64-i586 release [1665B] Получено: 3 http://ftp.altlinux.org p11/branch/noarch release [2831B] Получено 12,0kB за 0s (337kB/s). Найдено http://ftp.altlinux.org p11/branch/x86_64/classic pkglist Найдено http://ftp.altlinux.org p11/branch/x86_64/classic release Найдено http://ftp.altlinux.org p11/branch/x86_64/gostcrypto pkglist Найдено http://ftp.altlinux.org p11/branch/x86_64/gostcrypto release Найдено http://ftp.altlinux.org p11/branch/x86_64-i586/classic pkglist Найдено http://ftp.altlinux.org p11/branch/x86_64-i586/classic release Найдено http://ftp.altlinux.org p11/branch/noarch/classic pkglist Найдено http://ftp.altlinux.org p11/branch/noarch/classic release Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено ATTENTION: Your APT database is 1 days old. Please run 'apt-get update'! Running kernel: kernel-image-6.12-6.12.6-alt1 ``` Удалось случайно воспроизвести ошибку с похожим поведением на 1 сервере. И частично проанализировать, но не до конца. Ошибку выдает команда find /var/lib/apt/lists/ -name '*_pkglist.*' запущенная из fuse mounted directory (из /etc/pve) с текстом: find: Failed to save initial working directory: Transport endpoint is not connected (In reply to Alexander Makeenkov from comment #22) > ATTENTION: Your APT database is 1 days old. Please run 'apt-get update'! Описанная выше ситуация с fuse дает сообщение "database is stalled", но не "1 days old", как у вас. Следовательно, у вас какая-то другая причина. Пока она не воспроизводится пофиксить её нельзя так как не известно в чем причина. (Ответ для Alexander Makeenkov на комментарий #22) > Только что воспроизвелось на ALT Workstation K 11.0ALPHA: > > ``` > # apt-get update && update-kernel > Получено: 1 http://ftp.altlinux.org p11/branch/x86_64 release [4210B] > Получено: 2 http://ftp.altlinux.org p11/branch/x86_64-i586 release [1665B] > Получено: 3 http://ftp.altlinux.org p11/branch/noarch release [2831B] > Получено 12,0kB за 0s (337kB/s). > Найдено http://ftp.altlinux.org p11/branch/x86_64/classic pkglist > Найдено http://ftp.altlinux.org p11/branch/x86_64/classic release > Найдено http://ftp.altlinux.org p11/branch/x86_64/gostcrypto pkglist > Найдено http://ftp.altlinux.org p11/branch/x86_64/gostcrypto release > Найдено http://ftp.altlinux.org p11/branch/x86_64-i586/classic pkglist > Найдено http://ftp.altlinux.org p11/branch/x86_64-i586/classic release > Найдено http://ftp.altlinux.org p11/branch/noarch/classic pkglist > Найдено http://ftp.altlinux.org p11/branch/noarch/classic release > Чтение списков пакетов... Завершено > Построение дерева зависимостей... Завершено > ATTENTION: Your APT database is 1 days old. Please run 'apt-get update'! > Running kernel: kernel-image-6.12-6.12.6-alt1 > ``` Насколько я понимаю, причина в том, что действительно индексы на сервере не обновлялись указанное количество времени. При apt-get update индексы переносятся на локальную машину вместе с датой. В epm update это решено созданием фейкового *pkglist., который имеет дату последнего выполнения apt-get update и решает проблему с ложным информированием об устаревших индексах. Здравствуйте. Хотел рассказать о проблеме на alt-p11-kde-20250612-x86_64. Проверял на чистой системе после apt-get update && apt-get dist-upgrade -y && update-kernel -y При обновлении ядра пишет что ядро месячной давности Также выдаёт что база пакетов 1 дневной давности, хотя обновление только что проводилось |
Description
ruslandh 2023-07-20 06:15:15 MSK