You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
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.
The text was updated successfully, but these errors were encountered: