Bug 909577
Summary: | NM dispatcher script timeout warnings, scripts are killed | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | la_antorcha_guia |
Component: | NetworkManager | Assignee: | Dan Williams <dcbw> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 19 | CC: | cra, dcbw, jklimes, martian, orion |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-04-15 13:48:49 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
la_antorcha_guia
2013-02-09 16:13:54 UTC
The NM dispatcher uses 3 seconds timeout for the scripts. Is there any reason why the scripts should run that long? Did you inspect the scripts what they do? Did you modify them? E.g. 20-squid just reloads the squid configuration using systemctl: /bin/systemctl reload squid.service "killed" scripts are fedora default, but I have other script (supposed not killed in logs) that could take 6 seconds or more while connect remote machine. This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19 Do we really need to kill the scripts? Can we just stop waiting for them? I have a local script that restarts autofs, but that can take longer than 3 seconds - and killing leaves autofs down: Jan 21 11:25:46 paiute systemd: Started Network Manager Script Dispatcher Service. Jan 21 11:25:47 paiute nm-dispatcher.action: NetworkManagerDispatcher: performing autofs stop Jan 21 11:25:47 paiute NetworkManagerDispatcher: performing autofs stop Jan 21 11:25:47 paiute systemd: Stopping Automounts filesystems on demand... Jan 21 11:25:47 paiute automount[13514]: umount_autofs_indirect: ask umount returned busy /data Jan 21 11:25:49 paiute automount[13514]: umount_autofs_indirect: ask umount returned busy /home Jan 21 11:25:50 paiute nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/28-autofs' took too long; killing it. Jan 21 11:25:51 paiute systemd: Stopped Automounts filesystems on demand. (In reply to Orion Poplawski from comment #4) > Do we really need to kill the scripts? Can we just stop waiting for them? > I have a local script that restarts autofs, but that can take longer than 3 > seconds - and killing leaves autofs down: > > Jan 21 11:25:46 paiute systemd: Started Network Manager Script Dispatcher > Service. > Jan 21 11:25:47 paiute nm-dispatcher.action: NetworkManagerDispatcher: > performing autofs stop > Jan 21 11:25:47 paiute NetworkManagerDispatcher: performing autofs stop > Jan 21 11:25:47 paiute systemd: Stopping Automounts filesystems on demand... > Jan 21 11:25:47 paiute automount[13514]: umount_autofs_indirect: ask umount > returned busy /data > Jan 21 11:25:49 paiute automount[13514]: umount_autofs_indirect: ask umount > returned busy /home > Jan 21 11:25:50 paiute nm-dispatcher.action: Script > '/etc/NetworkManager/dispatcher.d/28-autofs' took too long; killing it. > Jan 21 11:25:51 paiute systemd: Stopped Automounts filesystems on demand. In the future NM will Just Wait Longer and yes, it could just continue without killing the script. I'm experiencing the same problem in Fedora 19. I can participate in testing reporting about this "feature" request if some developer would handle the implementation. *** This bug has been marked as a duplicate of bug 982734 *** |