Bug 19582 - [PATCH] Не всегда дожидается смерти dhcpcd
Summary: [PATCH] Не всегда дожидается смерти dhcpcd
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: etcnet (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: Mikhail Efremov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-11 15:12 MSD by Mikhail Efremov
Modified: 2019-03-13 16:48 MSK (History)
10 users (show)

See Also:


Attachments
dhcp_client_stop.patch (777 bytes, patch)
2009-04-11 15:14 MSD, Mikhail Efremov
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail Efremov 2009-04-11 15:12:36 MSD
При рестарте сети иногда вижу, что стартует новый dhcpcd до того, как завершился старый. Соответственно dhcpcd ругается, что  dhcpcd already running on pid ... и не завершается. Просто увеличивать DHCP_GRACE_TIME не хочется, указаных по дефолту 2 секунд ему как раз иногда чуть не хватает, бывает что и нормально стартует.
Предлагаю патч, одновременно можно в дефолтах увеличить значение DHCP_GRACE_TIME до секунд 5, с этим патчем вреда это не принесет, если dhcpcd помрет раньше - задержки в 5 секунд все равно не будет.
Comment 1 Mikhail Efremov 2009-04-11 15:14:16 MSD
Created attachment 3437 [details]
dhcp_client_stop.patch
Comment 2 Mikhail Efremov 2009-04-11 15:27:04 MSD
(In reply to comment #0)
> on pid ... и не завершается.
То бишь наоборот, завершается.
Comment 3 Anton Farygin 2009-05-25 01:35:39 MSD
у меня эта ошибка вылезает примерно в половине просыпаний ноутбуков.

с wlan0 слетает dhcp и я остюсь без IP на нём.
Comment 4 Denis Ovsienko 2009-06-15 01:05:59 MSD
Наконец добрался и до этого вопроса. Мотивация целиком понятна, и даже подскажу, что для остановки трудно поддающихся процессов можно использовать функцию kill_by_pidfile() из этого же файла. Единственное, что не ясно до конца --- почему используется SIGHUP. Кто-нибудь знает?
Comment 5 Mikhail Efremov 2009-06-15 02:40:15 MSD
> Единственное, что не ясно до конца
> --- почему используется SIGHUP. Кто-нибудь знает?

dhcpcd по SIGHUP посылает DHCPRELEASE перед выходом. По SIGTERM он этого не делает.
Comment 6 Sergey Bolshakov 2010-01-20 20:55:00 MSK
fixed in 0.9.10-alt2
Comment 7 Mikhail Efremov 2010-01-23 14:58:34 MSK
Думаю DHCP_GRACE_TIME в дефолтах теперь все-таки нужно увеличить. Сделанные изменения просто позволяют сделать это безболезненно.
Comment 8 Ivan Zakharyaschev 2010-02-22 15:38:00 MSK
Does https://bugzilla.altlinux.org/show_bug.cgi?id=18381 have the same cause?
Comment 9 Sergey Bolshakov 2010-02-22 15:50:26 MSK
doubt that
Comment 10 Mikhail Efremov 2015-05-20 20:59:09 MSK
С моим патчем из #30369 теперь стало еще хуже: dhcpcd --release на самом деле ждет максимум 10 секунд (прибиты гвоздями и не меняются), так что если dhcpcd не успел выйти за эти 10 секунд, то при network restart попытка запуска dhcpcd из ifup обламывается (т.к. предыдущий dhcpcd все еще запущен на этом интерфейсе, раньше после истечения DHCP_GRACE_TIME он всегда убивался kill -9). В результате после network restart сети нет.
Патч тут:
http://git.altlinux.org/people/sem/packages/etcnet.git?p=etcnet.git;a=commit;h=25b3be52af8dde38994cdf4bb6b2bf0f14fb984b

Там опять используется DHCP_GRACE_TIME и dhcpcd убивется kill -9 если не успел выйти. Также предлагаю все-таки увеличить DHCP_GRACE_TIME в дефолтах, хотя бы до 10 секунд (все равно при использовании dhcpcd --release задать меньшее время ожидания нельзя). Напоминаю, что это давно уже _максимальное_ время ожидания, а не безусловное. Так что вполне безопасно увеличивать его и до бОльших значений.
Comment 11 Repository Robot 2019-03-13 16:48:02 MSK
etcnet-0.9.18-alt2 -> sisyphus:

Mon Mar 11 2019 Andrey Bychkov <mrdrew@altlinux> 0.9.18-alt2
- iface status check for ifdown added (Closes: #22658)
- loading of kernel module 8021q disabled in VE (patch by Denis Yagofarov) (Closes: #13607)
- dhcpd service stop fixed (Closes: #19582)
- fixed unable to manage bridge ifaces on 2.6.32 OpenVZ kernels (patch by Nikolay A. Fetisov) (Closes: #33296)