#3897 reopened defect

Dhcpcd does not daemonize

Reported by: Ionut Vilsan Owned by: Sebastian Huber
Priority: normal Milestone: 6.1
Component: network/libbsd Version: 6
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description

Background: the DCHP client is started using the rc.conf script. In the background a new task dedicated to the dhcp client is created and then the dhcp client takes over this task. This works fine, we can get IP form the dhcp server and then take part in network communication based on IPv4.

Problem: The dhcp client cannot be stopped any time. Any shell commands will never reach the dhcpcd task, but rather it will instantiate a new dhcpd task which will take over the current task. E.g: in rtems console if you enter dhcpd -x, instead of killing the dhcpcd task a new dhcpcd task will be created which will run from the console. This means that the console cannot be used anymore.

There seems to be noway to communicate with the already created dhcpcd task.

I took a look over the dhcpcd in libbsd code and some of the features are turned off. Can someone give more details regarding this ?

Change History (5)

comment:1 Changed on Apr 3, 2020 at 3:01:19 PM by Sebastian Huber

Component: rtemsnetwork/libbsd
Priority: highnormal
Resolution: wontfix
Severity: majornormal
Status: assignedclosed

The dhcpcd is not intended to be started via a shell command. Maybe we should remove the shell command.

comment:2 in reply to:  1 Changed on Apr 14, 2020 at 10:47:44 PM by Chris Johns

Milestone: 6.1
Resolution: wontfix
Status: closedreopened
Version: 6

Replying to Sebastian Huber:

The dhcpcd is not intended to be started via a shell command. Maybe we should remove the shell command.

Reopening this bug. This is either a bug in dhcpcd (my view) or the rc.conf support needs to be enhanced to correctly support it. The rc.conf model uses working commands that are wrapped. On FreeBSD the wrapping is using shell scripts and on RTEMS it is a C framework. Another solution is to enhance the shell to push a command into the back ground.

I have stated before now and I will repeat what I have said, rc.conf is the documented method to use libbsd. I know of no other documented method and I am reluctant to expose and support other methods built on RTEMS internal specifics. If other methods exist and are in use then it is those users who are at risk of things changing and breaking on them. We fell into this hole in the legacy stack and I do not wish to repeat doing that here.

comment:3 Changed on Apr 14, 2020 at 11:51:19 PM by Joel Sherrill

Can you file a new ticket for a general solution to spawning a daemon that this ticket will use? Reference this ticket in that one.

comment:4 Changed on Apr 15, 2020 at 4:45:06 AM by Sebastian Huber

The RTEMS shell and the RTEMS rc.conf parser are two different things. This bug here is about controlling (e.g. stopping) the dhcpcd from the RTEMS shell. The dhcpcd is intended to be started at most once and then run forever.

comment:5 in reply to:  4 Changed on Apr 16, 2020 at 3:32:27 AM by Chris Johns

Replying to Sebastian Huber:

The RTEMS shell and the RTEMS rc.conf parser are two different things.

Is the rc.conf support for dhcpcd using the shell? I am not sure and I have not looked.

This bug here is about controlling (e.g. stopping) the dhcpcd from the RTEMS shell. The dhcpcd is intended to be started at most once and then run forever.

Is this related to our implementation or the upstream sources?

Note: See TracTickets for help on using tickets.