Bug 842358 - "service dhcpd restart" seems to hang for a long time
Summary: "service dhcpd restart" seems to hang for a long time
Status: RESOLVED DUPLICATE of bug 800365
Alias: None
Product: openSUSE 12.3
Classification: openSUSE
Component: Network (show other bugs)
Version: Final
Hardware: x86-64 openSUSE 12.3
: P5 - None : Major (vote)
Target Milestone: ---
Assignee: systemd maintainers
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 842359
  Show dependency treegraph
 
Reported: 2013-09-25 20:05 UTC by Mathias Homann
Modified: 2015-02-27 14:37 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathias Homann 2013-09-25 20:05:47 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0

When using "service dhcpd restart", the command seems to hang for a very long time, and then fail.
On closer inspection the script calls a command /usr/bin/systemd-tty-ask-password-agent which waits for a password... but there is no password prompt anywhere. Why would the root user have to confirm a service restart with a password???

Reproducible: Always

Steps to Reproduce:
1. "service dhcpd restart"
2. look at the process list
3. observe a /usr/bin/systemd-tty-ask-password-agent process
Actual Results:  
thbe dhcpd service does not start properly

Expected Results:  
a dhcp server is a basic cornerstone of a unix network. It should NOT be broken like this.
Comment 1 Marius Tomaschewski 2013-09-26 11:29:21 UTC
I've no idea why /usr/bin/systemd-tty-ask-password-agent were used.
There is not even the "X-Interactive" flag in the LSB header.

-> systemd.
Comment 2 Dr. Werner Fink 2013-09-26 11:51:31 UTC
Even if maintainer of systemd[1] I don't know
Comment 3 Frederic Crozat 2013-09-26 12:09:39 UTC
does it really wait for a password ? (the agent is started automatically and stopped automatically if a password request would be processed)

Do you have the same behaviour (hang) if you use :
systemctl --no-ask-password restart dhcpd.service

?
Comment 4 Mathias Homann 2013-09-26 12:17:31 UTC
yep, it hangs. in the process list i see these two:

root     19750  0.2  0.0  12140  1780 ?        Ss   14:16   0:00 /bin/bash /etc/init.d/dhcpd start
root     19876  0.0  0.0  37988  8040 ?        S    14:16   0:00  \_ /usr/sbin/dhcpd -4 -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid -chroot /var/lib/dhcp -lf /db/dhcpd.leases


looks to me as if dhcpd doesn't fork properly.
Comment 5 Mathias Homann 2013-09-26 12:18:15 UTC
(forgot to remove NEEDINFO)
Comment 6 Dr. Werner Fink 2013-09-26 12:26:49 UTC
(In reply to comment #4)

Which file descriptors had been opened by the /usr/sbin/dhcpd ... you may have a look into the directory /proc/$(pidofproc /usr/sbin/dhcpd)/fd with the ls command:

   ls -l /proc/$(pidofproc /usr/sbin/dhcpd)/fd/
Comment 7 Mathias Homann 2013-09-26 12:43:41 UTC
...found it.

got it...


the start script did not copy the file "/etc/bindresvport.blacklist" into the
chroot jail, so dhcpd refused to fork, and didn't open port 67 either.


akari:/etc/sysconfig # diff dhcpd~ dhcpd
128c128
< DHCPD_CONF_INCLUDE_FILES="/etc/dhcpd.d /etc/named.keys"
---
> DHCPD_CONF_INCLUDE_FILES="/etc/dhcpd.d /etc/named.keys /etc/bindresvport.blacklist"
154c154
< DHCPD_RUN_AS=""
---
> DHCPD_RUN_AS="dhcpd"
Comment 8 Dr. Werner Fink 2013-09-26 12:55:06 UTC
This does not answer my question: does dhcpd open a tty or stdout or stdin if not configured well?
Comment 9 Mathias Homann 2013-09-26 13:21:53 UTC
akari:/proc/7541/fd # l
insgesamt 0
dr-x------ 2 root root  0 26. Sep 15:21 ./
dr-xr-xr-x 8 root root  0 26. Sep 15:21 ../
lr-x------ 1 root root 64 26. Sep 15:21 0 -> /dev/null
l-wx------ 1 root root 64 26. Sep 15:21 1 -> /var/log/rc.dhcpd.log
l-wx------ 1 root root 64 26. Sep 15:21 2 -> /var/log/rc.dhcpd.log
lrwx------ 1 root root 64 26. Sep 15:21 20 -> socket:[87702]
lrwx------ 1 root root 64 26. Sep 15:21 21 -> socket:[87703]
lrwx------ 1 root root 64 26. Sep 15:21 3 -> socket:[87704]
lrwx------ 1 root root 64 26. Sep 15:21 4 -> socket:[87713]
aka
Comment 10 Dr. Werner Fink 2013-09-26 13:28:21 UTC
Ok and which of this sockets are used by systemd-tty-ask-password-agent as well?
Comment 11 Mathias Homann 2013-09-26 13:41:04 UTC
from what i can see, none.


akari:/proc/19815/fd # l
insgesamt 0
dr-x------ 2 root root  0 26. Sep 15:37 ./
dr-xr-xr-x 8 root root  0 26. Sep 15:35 ../
lr-x------ 1 root root 64 26. Sep 15:37 0 -> /dev/null
l-wx------ 1 root root 64 26. Sep 15:37 1 -> /var/log/rc.dhcpd.log
l-wx------ 1 root root 64 26. Sep 15:37 2 -> /var/log/rc.dhcpd.log
lrwx------ 1 root root 64 26. Sep 15:37 20 -> socket:[137060]
lrwx------ 1 root root 64 26. Sep 15:37 21 -> socket:[137061]
lrwx------ 1 root root 64 26. Sep 15:37 3 -> socket:[137062]
lrwx------ 1 root root 64 26. Sep 15:37 4 -> socket:[137070]
akari:/proc/19815/fd # 
akari:/proc/19681/fd # l
insgesamt 0
dr-x------ 2 root root  0 26. Sep 15:35 ./
dr-xr-xr-x 8 root root  0 26. Sep 15:35 ../
lrwx------ 1 root root 64 26. Sep 15:35 0 -> /dev/pts/0
lrwx------ 1 root root 64 26. Sep 15:35 1 -> /dev/pts/0
lrwx------ 1 root root 64 26. Sep 15:35 2 -> /dev/pts/0
lr-x------ 1 root root 64 26. Sep 15:35 3 -> /run/systemd/ask-password-block/136:0|
lr-x------ 1 root root 64 26. Sep 15:35 4 -> anon_inode:inotify
lrwx------ 1 root root 64 26. Sep 15:36 5 -> anon_inode:[signalfd]
akari:/proc/19681/fd # 




19681 is the systemd thing, 19815 is dhcpd...
Comment 12 systemd maintainers 2013-11-27 11:39:36 UTC
Is this bug still valid or does comment #7 describe how to fix this?
Comment 13 Mathias Homann 2013-11-27 14:46:36 UTC
yes, comment #7 describes the fix for this.
Comment 14 Thomas Blume 2015-02-27 14:37:58 UTC
Actually the password agent issue is a duplicate of bug 800365.

-> closing

*** This bug has been marked as a duplicate of bug 800365 ***