Opened on 03/04/20 at 10:29:59

Closed on 09/08/22 at 08:15:06

#3897 closed defect (wontfix)

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 (6)

comment:1 Changed on 04/03/20 at 15:01:19 by Sebastian Huber

Component: rtems → network/libbsd
Priority: high → normal
Resolution: → wontfix
Severity: major → normal
Status: assigned → closed

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 04/14/20 at 22:47:44 by Chris Johns

Milestone: → 6.1
Resolution: wontfix
Status: closed → reopened
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 04/14/20 at 23:51:19 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 04/15/20 at 04:45:06 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 04/16/20 at 03:32:27 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?

comment:6 Changed on 09/08/22 at 08:15:06 by Sebastian Huber

Resolution: → wontfix
Status: reopened → closed

The dhcpcd is intended to be started at most once and then run forever. This is a limitation of the libbsd port and related to the fact that RTEMS is a single process operating system.

Note: See TracTickets for help on using tickets.