stdout/stderr remain open after forking into the background

[lparkes]

It seems that dhcpcd doesn't close stout and stderr before forking off its children/background processes. This means that if some software runs /etc/rc.d/dhcpcd start | SOMETHING will never exit. It is somewhat ironic that last year I was almost complaining about stdout was closed when hooks were trying to print things out.

The pipe construct is quite useful to record the output from /etc/rc.d/dhcpcd start so that it can be displayed to the user in the event that something goes wrong while trying to start the dhcpcd service. The Azure agent for Linux (NetBSD) stops and starts the system DHCP client in order to run its own DHCP client if it can't get the azure endpoint from the system DHCP client. I have a perfectly reasonable workaround for this problem with the Azure agent, but I figure I should report the problem anyway because leaving stdout/stderr open is untidy at the least.

I'm assuming in the following session that process 1231 was the original dhcpcd that forked all the others off.

┌──(root☢)-[~]
└─# /etc/rc.d/dhcpcd start > foo 2>&1 ; lsof foo
COMMAND  PID    USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
dhcpcd  1231 _dhcpcd    1w  VREG  168,1       17 433499 foo
dhcpcd  1231 _dhcpcd    2w  VREG  168,1       17 433499 foo
dhcpcd  1647 _dhcpcd    1w  VREG  168,1       17 433499 foo
dhcpcd  1647 _dhcpcd    2w  VREG  168,1       17 433499 foo
dhcpcd  1648 _dhcpcd    1w  VREG  168,1       17 433499 foo
dhcpcd  1648 _dhcpcd    2w  VREG  168,1       17 433499 foo
┌──(root☢)-[~]
└─# lsof foo
COMMAND  PID    USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
dhcpcd  1647 _dhcpcd    1w  VREG  168,1       17 433499 foo
dhcpcd  1647 _dhcpcd    2w  VREG  168,1       17 433499 foo
dhcpcd  1648 _dhcpcd    1w  VREG  168,1       17 433499 foo
dhcpcd  1648 _dhcpcd    2w  VREG  168,1       17 433499 foo
┌──(root☢)-[~]
└─# ps alx|grep dhcpcd
 35 1647 1648   0  85  0  19440  1476 poll    S    ?      0:00.00 dhcpcd: [network proxy] 
 35 1648    1   0  85  0  18904  2180 poll    S    ?      0:00.00 dhcpcd: [manager] [ip4] [ip6] 
  0 1959 1648   0  85  0  18760  1736 poll    S    ?      0:00.00 dhcpcd: [privileged proxy] 
 35 2135 1648   0  85  0  18760  1416 poll    S    ?      0:00.00 dhcpcd: [control proxy] 
  0 2517 1747   0  85  0  20508  2056 pipe_rd O+   pts/0  0:00.00 grep dhcpcd 

[rsmarples]

We used to do that and ferry io back to the launcher process, but that proved error prone.
So I guess the real fix, in terms of Keep It Simple Stupid is to not log a detail to the launcher and just background unless the -B flag is present which I guess you wouldn't use in a pipe situation?

Somewhat related to #271

[lparkes]

That seems perfectly reasonable to me.