LINUX.ORG.RU
решено ФорумAdmin

Наглухо зависает df.

 ,


1

1

Алоха.
вот что сейчас висит:

# ps auxw | grep df
dbus       1052  0.0  0.0  37940  2764 ?        Ss   Mar02   7:23 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
root      87014  0.0  0.0 108020   776 ?        D    Sep21   0:00 df -h
root     117456  0.0  0.0 108020   776 pts/2    D+   15:47   0:00 df -h
root     117606  0.0  0.0  27168  1148 ?        Ss   Sep13   0:23 /usr/sbin/xinetd -stayalive -pidfile /var/run/xinetd.pid
root     118033  0.0  0.0 108020   776 pts/3    D+   15:52   0:00 df
root     118808  0.0  0.0 112708   968 pts/4    S+   16:00   0:00 grep --color=auto df

kill не помогает.
вот что в логах:

[17542990.344150] INFO: task df:87014 blocked for more than 120 seconds.
[17542990.344159] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[17542990.344163] df              D ffff88042e713680     0 87014 126762 0x00000084
[17542990.344173]  ffff88010ab1fa30 0000000000000082 ffff8801c2522d80 ffff88010ab1ffd8
[17542990.344180]  ffff88010ab1ffd8 ffff88010ab1ffd8 ffff8801c2522d80 ffff880427677098
[17542990.344187]  ffff8804276770a0 7fffffffffffffff ffff8801c2522d80 ffff880423261f00
[17542990.344194] Call Trace:
[17542990.344210]  [<ffffffff81609259>] schedule+0x29/0x70
[17542990.344216]  [<ffffffff816071a9>] schedule_timeout+0x209/0x2d0
[17542990.344225]  [<ffffffff810980e6>] ? finish_wait+0x56/0x70
[17542990.344231]  [<ffffffff816075f2>] ? mutex_lock+0x12/0x2f
[17542990.344238]  [<ffffffff8124a6fa>] ? autofs4_wait+0x37a/0x870
[17542990.344246]  [<ffffffff81609756>] wait_for_completion+0x116/0x170
[17542990.344251]  [<ffffffff810a94d0>] ? wake_up_state+0x20/0x20
[17542990.344257]  [<ffffffff8124b85b>] autofs4_expire_wait+0x6b/0x110
[17542990.344262]  [<ffffffff81248952>] do_expire_wait+0x172/0x190
[17542990.344268]  [<ffffffff81248b7b>] autofs4_d_manage+0x9b/0x160
[17542990.344277]  [<ffffffff811d0aa5>] follow_managed+0xb5/0x300
[17542990.344284]  [<ffffffff811d13bb>] lookup_fast+0x19b/0x2e0
[17542990.344290]  [<ffffffff811d48f5>] path_lookupat+0x165/0x7a0
[17542990.344298]  [<ffffffff8115edb6>] ? free_hot_cold_page_list+0x46/0xa0
[17542990.344306]  [<ffffffff811ab515>] ? kmem_cache_alloc+0x35/0x1d0
[17542990.344311]  [<ffffffff811d6abf>] ? getname_flags+0x4f/0x190
[17542990.344316]  [<ffffffff811d4f5b>] filename_lookup+0x2b/0xc0
[17542990.344321]  [<ffffffff811d7937>] user_path_at_empty+0x67/0xc0
[17542990.344331]  [<ffffffff810f0a62>] ? from_kgid_munged+0x12/0x20
[17542990.344336]  [<ffffffff811cb99f>] ? cp_new_stat+0x14f/0x180
[17542990.344342]  [<ffffffff811d79a1>] user_path_at+0x11/0x20
[17542990.344347]  [<ffffffff811cb493>] vfs_fstatat+0x63/0xc0
[17542990.344353]  [<ffffffff811cb9fe>] SYSC_newstat+0x2e/0x60
[17542990.344361]  [<ffffffff810fac56>] ? __audit_syscall_exit+0x1f6/0x2a0
[17542990.344367]  [<ffffffff811cbcde>] SyS_newstat+0xe/0x10
[17542990.344375]  [<ffffffff81613da9>] system_call_fastpath+0x16/0x1b

вопросы: зачем висит df ?
если я сделаю disable this message - это решение ?
# uname -a
Linux hostname 3.10.0-229.el7.x86_64 #1 SMP Thu Jan 29 18:37:38 EST 2015 x86_64 x86_64 x86_64 GNU/Linux

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.5 (Maipo)

★★★★★

df висит пытаясь прочитать что-то.

У тебя либо проблемы с диском, либо проблемы с битой fs.

Либо и то и другое вместе.

zgen ★★★★★
()

autofs4

Скорее всего какая-то автомонтируемая (сетевая) фс накрылась, вот и ждет (зависает).

anonymous
()

пройдись смартом по дискам для начала.

anonymous
()
Ответ на: комментарий от Pyzia

Обычный ворнинг, который вылазит например при сваппинге.

anonymous
()
Ответ на: комментарий от zgen

df висит пытаясь прочитать что-то.

почему он с ошибкой не отваливается и не выдает полезную инфу ?

dada ★★★★★
() автор топика
Ответ на: комментарий от dada

Потому что она не может, тк используются блокирующие сисвызовы в один поток.

anonymous
()
Ответ на: комментарий от zgen

ничего сетевого:

# mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=8117636k,nr_inodes=2029409,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mapper/rhel-root on / type xfs (rw,relatime,attr2,inode64,noquota)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=32,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
/dev/mapper/rhel-home on /home type xfs (rw,relatime,attr2,inode64,noquota)
/dev/sda1 on /boot type xfs (rw,relatime,attr2,inode64,noquota)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
tmpfs on /run/user/241600006 type tmpfs (rw,nosuid,nodev,relatime,size=1625508k,mode=700,uid=241600006,gid=241600006)
tmpfs on /run/user/241600001 type tmpfs (rw,nosuid,nodev,relatime,size=1625508k,mode=700,uid=241600001,gid=241600001)
tmpfs on /run/user/241600024 type tmpfs (rw,nosuid,nodev,relatime,size=1625508k,mode=700,uid=241600024,gid=241600024)
tmpfs on /run/user/42 type tmpfs (rw,nosuid,nodev,relatime,size=1625508k,mode=700,uid=42,gid=42)

dada ★★★★★
() автор топика
Ответ на: комментарий от Deleted

да.
моунт я уже выложил.

dada ★★★★★
() автор топика
Ответ на: комментарий от dada
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=32,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
 


Ну ты понял. Выпиливай парашу

mittorn ★★★★★
()

Как минимум, можно запустить strace df и посмотреть, на чем оно затыкается.

Также, раз в трейсе есть упоминания autofs, не лишним будет заглянуть в /etc/auto.master и прочие его конфигурационные файлы.

Deleted
()
Ответ на: комментарий от Deleted

там и так видно, что на newstat и autofs завязан.
Выше палится парашад-1 с autofs. Таймаут там кстати 300 секунд, то есть через 5 минут df должен отвиснуть

mittorn ★★★★★
()
Ответ на: комментарий от dada

systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=32,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)

Есть подозрения, что мейнтейнеры твоего дистра намудрили с зависимостями systemd-юнитов, дедлок на закольцованном графе зависимостей.
Redhat пишет systemd, но не умеет им пользоваться.

anonymous
()
Ответ на: комментарий от Deleted

Значит уходить с rhel. Правда, не понятно, куда

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

что-то с твоим планом не так =)
df висит с 21-го сентября.

dada ★★★★★
() автор топика
Ответ на: комментарий от post-factum

Там написано:

This is caused by a bug. The bug has been fixed in systemd-219-57.el7 and is part of RHBA-2018:0711.

а у меня:

]# rpm -qa | grep systemd
systemd-libs-219-57.el7_5.1.x86_64
systemd-sysv-219-57.el7_5.1.x86_64
systemd-python-219-57.el7_5.1.x86_64
systemd-219-57.el7_5.1.x86_64

dada ★★★★★
() автор топика
Ответ на: комментарий от post-factum

Спасибо тебе добрый человек!

# systemctl mask proc-sys-fs-binfmt_misc.automount
Created symlink from /etc/systemd/system/proc-sys-fs-binfmt_misc.automount to /dev/null.
# systemctl stop proc-sys-fs-binfmt_misc.automount
# df -h
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/rhel-root   88G   34G   54G  39% /
devtmpfs               7.8G     0  7.8G   0% /dev
tmpfs                  7.8G   84K  7.8G   1% /dev/shm
tmpfs                  7.8G  744M  7.1G  10% /run
tmpfs                  7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/mapper/rhel-home   10G  3.3G  6.7G  34% /home
/dev/sda1              497M  172M  325M  35% /boot
tmpfs                  1.6G     0  1.6G   0% /run/user/241600006
tmpfs                  1.6G  4.0K  1.6G   1% /run/user/241600001
tmpfs                  1.6G     0  1.6G   0% /run/user/241600024
tmpfs                  1.6G     0  1.6G   0% /run/user/42
dada ★★★★★
() автор топика
Ответ на: комментарий от post-factum

Содержательный ответ. В чем проблема? Почему она до сих пор вылезает? Автомаунт, у которого mount-юнит кривой и блочится? Или в том, что systemd использует метаданные фс (название файла) как данные посредством уродливого экранирования? Может запихнуть данные в метаданные, например, ввести расширенный атрибут systemd.mountpoint. А чего мелочиться, сразу весь ман systemd.unit в атрибуты?

anonymous
()

disable this message только уберет сообщение, не решая проблему.
df висит по причинам, что ядро, вероятно, потеряло железку (винт/рэйд) по неведомым мне причинам.
либо ребут спасет, либо железка подыхает.
оказывается в шапке и такое бывает.

SevikL ★★★★★
()
Последнее исправление: SevikL (всего исправлений: 1)
Ответ на: комментарий от moot

Воистину! Надо все отправить в /dev/null Нет демонов, нет проблемы.

anc ★★★★★
()
Ответ на: комментарий от post-factum

Обстоятельный ответ в виде «замаскируй и останови всё, что не работает», который уже здесь приведен?

anonymous
()
Ответ на: комментарий от post-factum

- У меня не работает ваша кофеварка. - У вы не пользуйтесь ей. Можете попросить кофе на ресепшне. Мы рассмотрим вашу просьбу. - Как это мило. - И вам хорошего дня.

anonymous
()
15 сентября 2020 г.
Ответ на: комментарий от post-factum

здравствуйте. такая же ситуация возникла (скрипт с df -h висит уже 2 дня). непосредственный вызов df тоже зависал, но сейчас работает нормально (после того, как примонтировал один из сетевых ресурсов). команды по остановке proc-sys-fs-binfmt_misc.automount на всякий случай тоже выполнил (у нас еще более старый oracle linux 7.1) вопрос 1 - можно ли убить этот процесс (и завершить уже скрипт) без перезагрузки? kill не помогает вопрос 2 - скрипт (бэкап oracle db) запускается каждый выходной уже несколько лет. df отрабатывал до сих пор нормально даже при недоступной по выходным сетевой шаре. что могло случиться сейчас?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.