Bug 19582

Summary: [PATCH] Не всегда дожидается смерти dhcpcd
Product: Sisyphus Reporter: Mikhail Efremov <sem>
Component: etcnetAssignee: Mikhail Efremov <sem>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: normal    
Priority: P3 CC: glebfm, gray_graff, imz, iv, ldv, mike, rider, sem, shaba, vseleznv
Version: unstable   
Hardware: all   
OS: Linux   
Attachments:
Description Flags
dhcp_client_stop.patch none

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)