I am using the ISC DHCP server (dhcpd) version 4.3.6 from a rocko Yocto
build. When dhcpd is started without the '-f' or '-d' options (forks to
the background) it does not work. DHCP DISCOVER requests are sent, but
the dhcpd application does not respond. I can attach strace to the
dhcpd process and see that dhcpd just sleeps in an futex() call.
If I start dhcpd with either the '-f' or '-d' options so it does not
fork, then it works properly.
I have run dhcpd (both forking and non forking) using strace to see if I
could spot any differences. The only thing I notice is that when
forking, the parent process terminates (expected) along with 3 other
child processes/threads. It looks like these other threads are supposed
to handle the ISC tasks/messages, but are not cloned by the fork and are
not present after forking.
For reference, with an older version of ISC DHCP server (4.1.1-P1) on an
older product, this problem does not occur.
On Mon, Jan 6, 2020, 1:42 PM Jay Foster <[hidden email]> wrote:
I am using the ISC DHCP server (dhcpd) version 4.3.6 from a rocko Yocto
build. When dhcpd is started without the '-f' or '-d' options (forks to
the background) it does not work. DHCP DISCOVER requests are sent, but
the dhcpd application does not respond. I can attach strace to the
dhcpd process and see that dhcpd just sleeps in an futex() call.
If I start dhcpd with either the '-f' or '-d' options so it does not
fork, then it works properly.
I have run dhcpd (both forking and non forking) using strace to see if I
could spot any differences. The only thing I notice is that when
forking, the parent process terminates (expected) along with 3 other
child processes/threads. It looks like these other threads are supposed
to handle the ISC tasks/messages, but are not cloned by the fork and are
not present after forking.
For reference, with an older version of ISC DHCP server (4.1.1-P1) on an
older product, this problem does not occur.
Can you be more specific? /usr/sbin/dhcpd is root:root.
/usr/sbin/dhcpd is being run as root.
On 1/6/2020 12:58 PM, Christopher Barry
wrote:
Make sure user/group perms are valid.
On Mon, Jan 6, 2020, 1:42 PM
Jay Foster <[hidden email]> wrote:
I am using
the ISC DHCP server (dhcpd) version 4.3.6 from a rocko Yocto
build. When dhcpd is started without the '-f' or '-d' options
(forks to
the background) it does not work. DHCP DISCOVER requests are
sent, but
the dhcpd application does not respond. I can attach strace
to the
dhcpd process and see that dhcpd just sleeps in an futex()
call.
If I start dhcpd with either the '-f' or '-d' options so it
does not
fork, then it works properly.
I have run dhcpd (both forking and non forking) using strace
to see if I
could spot any differences. The only thing I notice is that
when
forking, the parent process terminates (expected) along with 3
other
child processes/threads. It looks like these other threads
are supposed
to handle the ISC tasks/messages, but are not cloned by the
fork and are
not present after forking.
For reference, with an older version of ISC DHCP server
(4.1.1-P1) on an
older product, this problem does not occur.
Generally, when backgrounded, dhcpd runs with reduced privs, e.g. as dhcpd:dhcpd (your configured user/group may be different). Can you su as that user and run dhcpd in the foreground? I'm suspecting that user may not have write perms to the leases file.
On Mon, Jan 6, 2020, 4:15 PM Jay Foster <[hidden email]> wrote:
Can you be more specific? /usr/sbin/dhcpd is root:root.
/usr/sbin/dhcpd is being run as root.
On 1/6/2020 12:58 PM, Christopher Barry
wrote:
Make sure user/group perms are valid.
On Mon, Jan 6, 2020, 1:42 PM
Jay Foster <[hidden email]> wrote:
I am using
the ISC DHCP server (dhcpd) version 4.3.6 from a rocko Yocto
build. When dhcpd is started without the '-f' or '-d' options
(forks to
the background) it does not work. DHCP DISCOVER requests are
sent, but
the dhcpd application does not respond. I can attach strace
to the
dhcpd process and see that dhcpd just sleeps in an futex()
call.
If I start dhcpd with either the '-f' or '-d' options so it
does not
fork, then it works properly.
I have run dhcpd (both forking and non forking) using strace
to see if I
could spot any differences. The only thing I notice is that
when
forking, the parent process terminates (expected) along with 3
other
child processes/threads. It looks like these other threads
are supposed
to handle the ISC tasks/messages, but are not cloned by the
fork and are
not present after forking.
For reference, with an older version of ISC DHCP server
(4.1.1-P1) on an
older product, this problem does not occur.
dhcpd is running as root whether or not it forks (evidenced by ps).
I do not see how forking or not forking has any bearing on
permissions. dhcpd does not report any errors writing the leases
file (daemon.info dhcpd: Wrote 1 leases to leases file.).
For grins, I chown dhcp:dhcp both the leases file and .conf file.
Makes no difference. Also tried adding '-user dhcp -group dhcp'.
Also makes no difference.
There is no evidence of any kind of a permissions issue. strace
shows that dhcpd creates 3 child processes via clone(2). These
processes seem to be associated with the dhcp_context_create(),
omapi_init(), etc. function calls. In the forking case, these get
terminated along with the parent process after the fork(2), but
obviously do not when not forking. That is the only difference that
I see between the forking and non-forking invocations.
On 1/6/2020 1:49 PM, Christopher Barry
wrote:
Generally, when backgrounded, dhcpd runs with
reduced privs, e.g. as dhcpd:dhcpd (your configured user/group
may be different). Can you su as that user and run dhcpd in the
foreground? I'm suspecting that user may not have write perms to
the leases file.
On Mon, Jan 6, 2020, 4:15 PM
Jay Foster <[hidden email]> wrote:
Can you be more
specific? /usr/sbin/dhcpd is root:root. /usr/sbin/dhcpd is
being run as root.
On 1/6/2020 12:58 PM, Christopher Barry wrote:
Make sure user/group perms are valid.
On Mon, Jan 6, 2020,
1:42 PM Jay Foster <[hidden email]>
wrote:
I am
using the ISC DHCP server (dhcpd) version 4.3.6 from a
rocko Yocto
build. When dhcpd is started without the '-f' or '-d'
options (forks to
the background) it does not work. DHCP DISCOVER
requests are sent, but
the dhcpd application does not respond. I can attach
strace to the
dhcpd process and see that dhcpd just sleeps in an
futex() call.
If I start dhcpd with either the '-f' or '-d' options
so it does not
fork, then it works properly.
I have run dhcpd (both forking and non forking) using
strace to see if I
could spot any differences. The only thing I notice
is that when
forking, the parent process terminates (expected)
along with 3 other
child processes/threads. It looks like these other
threads are supposed
to handle the ISC tasks/messages, but are not cloned
by the fork and are
not present after forking.
For reference, with an older version of ISC DHCP
server (4.1.1-P1) on an
older product, this problem does not occur.
For now, I am working around this issue by telling dhcpd not to fork
(-f option) and instead forking the shell (append ' &' to the
command line).
On 1/6/2020 2:02 PM, Jay Foster wrote:
dhcpd is running as root whether or not it forks (evidenced by
ps). I do not see how forking or not forking has any bearing on
permissions. dhcpd does not report any errors writing the leases
file (daemon.info dhcpd: Wrote 1 leases to leases file.).
For grins, I chown dhcp:dhcp both the leases file and .conf file.
Makes no difference. Also tried adding '-user dhcp -group dhcp'.
Also makes no difference.
There is no evidence of any kind of a permissions issue. strace
shows that dhcpd creates 3 child processes via clone(2). These
processes seem to be associated with the dhcp_context_create(),
omapi_init(), etc. function calls. In the forking case, these get
terminated along with the parent process after the fork(2), but
obviously do not when not forking. That is the only difference
that I see between the forking and non-forking invocations.
On 1/6/2020 1:49 PM, Christopher
Barry wrote:
Generally, when backgrounded, dhcpd runs with
reduced privs, e.g. as dhcpd:dhcpd (your configured user/group
may be different). Can you su as that user and run dhcpd in
the foreground? I'm suspecting that user may not have write
perms to the leases file.
On Mon, Jan 6, 2020, 4:15 PM
Jay Foster <[hidden email]> wrote:
Can you be more
specific? /usr/sbin/dhcpd is root:root. /usr/sbin/dhcpd
is being run as root.
On 1/6/2020 12:58 PM, Christopher Barry wrote:
Make sure user/group perms are valid.
On Mon, Jan 6, 2020,
1:42 PM Jay Foster <[hidden email]>
wrote:
I
am using the ISC DHCP server (dhcpd) version 4.3.6
from a rocko Yocto
build. When dhcpd is started without the '-f' or
'-d' options (forks to
the background) it does not work. DHCP DISCOVER
requests are sent, but
the dhcpd application does not respond. I can
attach strace to the
dhcpd process and see that dhcpd just sleeps in an
futex() call.
If I start dhcpd with either the '-f' or '-d'
options so it does not
fork, then it works properly.
I have run dhcpd (both forking and non forking)
using strace to see if I
could spot any differences. The only thing I notice
is that when
forking, the parent process terminates (expected)
along with 3 other
child processes/threads. It looks like these other
threads are supposed
to handle the ISC tasks/messages, but are not cloned
by the fork and are
not present after forking.
For reference, with an older version of ISC DHCP
server (4.1.1-P1) on an
older product, this problem does not occur.
Yes, SELINUX is in use, but it is set to permissive. Also, if SELINUX
was causing a problem, then it would do so in both the forking and
non-forking invocations.
On 1/6/2020 1:50 PM, Bruce Hudson wrote:
> Is your system running SELINUX? If it is a custom build, the
> secure environment rules, normally only envoked for daemons, may
> not be allowing the server to access things; even with the
> correct file permissions.
>
> Violations should be logged, or temporarily turn off security
> with "setenforce 0".
Locked
