Вопросы Теги

systemd-разрешение высокой производительности процессора после обновления до 17.04

Недавно я обновил свой Xubuntu с 16.10 по 17.04.

Все работает хорошо, кроме systemd-resolve. несколько раз это делает использование процессора слишком высоким, и я не знаю, почему эта проблема была достигнута.

И вот вывод команды top:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1114 systemd+ 20 0 51532 6744 4504 R 100 0.0 9:51.67 systemd-resolve 1152 dnsmasq 20 0 64360 2892 2480 R 38.9 0.0 4:05.53 dnsmasq 1245 root 20 0 376644 89644 64436 S 1.7 0.5 0:35.69 Xorg 1624 asus 20 0 370160 45820 28488 S 0.7 0.3 0:00.90 python2 2238 asus 20 0 2562816 553112 128492 S 0.7 3.4 2:41.20 firefox 16 root 20 0 0 0 0 S 0.3 0.0 0:01.05 ksoftirqd/1 708 root -51 0 0 0 0 S 0.3 0.0 0:01.20 irq/95-ELAN1000 1302 root -51 0 0 0 0 S 0.3 0.0 0:03.68 irq/142-nvidia 1734 asus 20 0 483388 11060 8560 S 0.3 0.1 0:05.45 conky 2820 root 20 0 0 0 0 S 0.3 0.0 0:00.14 kworker/5:1 3420 asus 20 0 53384 3932 3200 R 0.3 0.0 0:00.76 top

(я использую tor и obfs4proxy, это может быть полезно для ответа)

(я использую tor и obfs4proxy), но обычно это происходит при запуске некоторых команд, таких как sudo apt update.

22
задан 27 April 2017 в 17:50

9 ответов

У меня был аналогичный конфликт между systemd-resol и dnsmasq на порту 53.

https://unix.stackexchange.com/questions/304050/how-to-avoid-conflicts-between-dnsmasq -and-systemd-resolved

и

https://unix.stackexchange.com/questions/304050/how-to-avoid-conflicts-between-dnsmasq- and-systemd-resolved

заставил меня добавить DNSStubListener=no в /etc/systemd/resolved.conf, а затем sudo service systemd-resolved restart.

29
ответ дан 22 May 2018 в 23:09
  • 1
    Это сработало, но потом у меня не было DNS и я не мог получить доступ к веб-сайтам по имени. – abalter 14 September 2017 в 07:43
  • 2
    @abalter. Моя проблема была конкретно в цикле между systemd-resol и dnsmasq, поэтому отключение работало для меня. Если у вас все еще есть эта проблема, мне будет интересно, как выглядит ваш top, и если это покажет цикл между systemd-resol и другой утилитой. – MetricMike 20 September 2017 в 03:45
  • 3
    Да, делает ли это resolved то же самое, что и dnsmasq? Должны ли мы отключить одного из них навсегда? Поскольку на самом деле нет смысла иметь два локальных dns-резольвера (я все еще не убежден в одном TBH, но я решил пойти с потоком, а не настраивать свой конфиг) – Ivan Anishchuk 27 November 2017 в 22:59
  • 4
    omg ... это было так хорошо. безмолвие моего вентилятора процессора сразу же после перезапуска systemd-разрешено ... но теперь хром, похоже, доходит до 100? – Jonny Asmar 29 December 2017 в 22:27
  • 5
    Yeh - это решение, казалось, имело нежелательные побочные эффекты (включая убийство thunderbird) ... См. Ниже ответ от markackerman за трюк, который сработал для меня. – Jonny Asmar 29 December 2017 в 22:31

У меня был аналогичный конфликт между systemd-resol и dnsmasq на порту 53.

https://unix.stackexchange.com/questions/304050/how-to-avoid-conflicts-between-dnsmasq -and-systemd-resolved

и

https://unix.stackexchange.com/questions/304050/how-to-avoid-conflicts-between-dnsmasq- and-systemd-resolved

заставил меня добавить DNSStubListener=no в /etc/systemd/resolved.conf, а затем sudo service systemd-resolved restart.

28
ответ дан 18 July 2018 в 14:09

У меня был аналогичный конфликт между systemd-resol и dnsmasq на порту 53.

https://unix.stackexchange.com/questions/304050/how-to-avoid-conflicts-between-dnsmasq -and-systemd-resolved

и

https://unix.stackexchange.com/questions/304050/how-to-avoid-conflicts-between-dnsmasq- and-systemd-resolved

заставил меня добавить DNSStubListener=no в /etc/systemd/resolved.conf, а затем sudo service systemd-resolved restart.

28
ответ дан 24 July 2018 в 20:20

Вызванные проблемы с другими приложениями (teamViewer в моем случае)

Предлагаемые другими шагами решения

Добавьте строку DNSMASQ_EXCEPT=lo в /etc/default/dnsmasq 

sudo nano /etc/default/dnsmasq

Перезагрузите dnsmasq через 

sudo service systemd-resolved restart

Скажите спасибо Если я помог, он вернулся к нормальному состоянию и не витает с другими приложениями, как предыдущий метод DID.

Приветствия, Марк

10
ответ дан 22 May 2018 в 23:09
  • 1
    sudo nano не является способом редактирования конфигов, вместо этого следует использовать sudoedit. И systemctl - это способ перезапуска служб с помощью systemd. Прежде всего, это не работает для меня, я все еще вижу 100% использование ЦП. – Ivan Anishchuk 27 November 2017 в 22:51
  • 2
    И разве это не эффективно отключает dnsmasq? Почему бы не отключить его полностью? – Ivan Anishchuk 27 November 2017 в 23:16

systemd-resolved сходит с ума, когда кто-то модифицирует файл /etc/resolv.conf, который должен указывать на собственный адрес прослушивания 127.0.0.53.

. Кто-то может быть любым скриптом, инициированным сетевыми событиями ( VPN, идущий вверх или вниз, DHCP и т. Д.)

Если вы вернете сервер имен обратно в 127.0.0.53, то systemd-resolved «успокоится» несколько секунд спустя.

Предполагая, что все соблюдают правила и только используя resolvconf для изменения конфигурации резольвера, вы также можете сделать это:

В файле /etc/resolvconf/interface-order указан порядок, в котором будут использоваться серверы имен, в зависимости от сетевого интерфейса они были получены от.

Если вы добавите запись для systemd-resolved в начало файла, она всегда будет считаться первой, и файл не будет изменен.

4
ответ дан 22 May 2018 в 23:09
  • 1
    Таким образом, оба ответа выше закончились тем, что я не смог в конце концов. Но этот человек вел себя так же, как и прогнозировалось. По умолчанию мне удалось отключить мой resolv.conf (для сервера имен было установлено 127.0.0.1). Даже не нужно было перезапускать systemd, и все оставалось снова. Наблюдая за моими процессами, dnsmasq снова отключается от радара, где он должен быть! ЭТО должен быть принятым ответом. Спасибо @xalkina! – Jonny Asmar 29 December 2017 в 22:51
  • 2
    Кажется, что эта проблема возвращается после перезагрузки ... Любые идеи, которые будут изменять мою resolv.conf? – Jonny Asmar 1 January 2018 в 00:15
  • 3
    Это решение работает и для меня (в то время как два выше этого не делают) – Alex Hoppus 21 January 2018 в 16:55

Вызванные проблемы с другими приложениями (teamViewer в моем случае)

Предлагаемые другими шагами решения

Добавьте строку DNSMASQ_EXCEPT=lo в /etc/default/dnsmasq

sudo nano /etc/default/dnsmasq

Перезагрузите dnsmasq через

sudo service systemd-resolved restart

Скажите спасибо Если я помог, он вернулся к нормальному состоянию и не витает с другими приложениями, как предыдущий метод DID.

Приветствия, Марк

14
ответ дан 18 July 2018 в 14:09

systemd-resolved сходит с ума, когда кто-то модифицирует файл /etc/resolv.conf, который должен указывать на собственный адрес прослушивания 127.0.0.53.

. Кто-то может быть любым скриптом, инициированным сетевыми событиями ( VPN, идущий вверх или вниз, DHCP и т. Д.)

Если вы вернете сервер имен обратно в 127.0.0.53, то systemd-resolved «успокоится» несколько секунд спустя.

Предполагая, что все соблюдают правила и только используя resolvconf для изменения конфигурации резольвера, вы также можете сделать это:

В файле /etc/resolvconf/interface-order указан порядок, в котором будут использоваться серверы имен, в зависимости от сетевого интерфейса они были получены от.

Если вы добавите запись для systemd-resolved в начало файла, она всегда будет считаться первой, и файл не будет изменен.

6
ответ дан 18 July 2018 в 14:09

Вызванные проблемы с другими приложениями (teamViewer в моем случае)

Предлагаемые другими шагами решения

Добавьте строку DNSMASQ_EXCEPT=lo в /etc/default/dnsmasq

sudo nano /etc/default/dnsmasq

Перезагрузите dnsmasq через

sudo service systemd-resolved restart

Скажите спасибо Если я помог, он вернулся к нормальному состоянию и не витает с другими приложениями, как предыдущий метод DID.

Приветствия, Марк

14
ответ дан 24 July 2018 в 20:20
  • 1
    sudo nano не является способом редактирования конфигов, вместо этого следует использовать sudoedit. И systemctl - это способ перезапуска служб с помощью systemd. Прежде всего, это не работает для меня, я все еще вижу 100% использование ЦП. – Ivan Anishchuk 27 November 2017 в 22:51
  • 2
    И разве это не эффективно отключает dnsmasq? Почему бы не отключить его полностью? – Ivan Anishchuk 27 November 2017 в 23:16

systemd-resolved сходит с ума, когда кто-то модифицирует файл /etc/resolv.conf, который должен указывать на собственный адрес прослушивания 127.0.0.53.

. Кто-то может быть любым скриптом, инициированным сетевыми событиями ( VPN, идущий вверх или вниз, DHCP и т. Д.)

Если вы вернете сервер имен обратно в 127.0.0.53, то systemd-resolved «успокоится» несколько секунд спустя.

Предполагая, что все соблюдают правила и только используя resolvconf для изменения конфигурации резольвера, вы также можете сделать это:

В файле /etc/resolvconf/interface-order указан порядок, в котором будут использоваться серверы имен, в зависимости от сетевого интерфейса они были получены от.

Если вы добавите запись для systemd-resolved в начало файла, она всегда будет считаться первой, и файл не будет изменен.

6
ответ дан 24 July 2018 в 20:20
  • 1
    Таким образом, оба ответа выше закончились тем, что я не смог в конце концов. Но этот человек вел себя так же, как и прогнозировалось. По умолчанию мне удалось отключить мой resolv.conf (для сервера имен было установлено 127.0.0.1). Даже не нужно было перезапускать systemd, и все оставалось снова. Наблюдая за моими процессами, dnsmasq снова отключается от радара, где он должен быть! ЭТО должен быть принятым ответом. Спасибо @xalkina! – Jonny Asmar 29 December 2017 в 22:51
  • 2
    Кажется, что эта проблема возвращается после перезагрузки ... Любые идеи, которые будут изменять мою resolv.conf? – Jonny Asmar 1 January 2018 в 00:15
  • 3
    Это решение работает и для меня (в то время как два выше этого не делают) – Alex Hoppus 21 January 2018 в 16:55

Другие вопросы по тегам:

Похожие вопросы: