Change Details

During developing https://github.com/vyos/vyos-1x/pull/2179, I found `vyos.utils.process.call` could hang when starting an FRR daemon. Steps to produce this issue: ``` # ensure igmp protocol is disabled delete protocols igmp commit # enable igmp protocol, which will cause pimd to start set protocols igmp interface eth0 commit # hangs here ``` I found it hanged at `pipe = p.communicate(input, timeout)` (https://github.com/vyos/vyos-1x/blob/fc35434bfb0def50e5e492030451e035c80d153d/python/vyos/utils/process.py#L82) when `call(f'vtysh -d pimd -f {config_file}')` is called at (https://github.com/vyos/vyos-1x/blob/fc35434bfb0def50e5e492030451e035c80d153d/src/conf_mode/protocols_igmp.py#L125). At the same time, `ps -ef | grep pimd` showed that pimd was `<defunct>`: ``` frr 68972 68968 0 06:52 pts/1 00:00:00 [pimd] <defunct> frr 68973 1 0 06:52 ? 00:00:00 /usr/lib/frr/pimd -d -F traditional --daemon -A 127.0.0.1 ``` By looking at this issue closer, I found it was similar to https://stackoverflow.com/questions/50646412/subprocess-becomes-defunct-communicate-hangs. Changing stdout and stderr from PIPE to None solved the issue: ``` call(f'vtysh -d pimd -f {config_file}', stdout=None, stderr=None) ``` It seems to me that when calling `call(f'vtysh -d pimd -f {config_file}')` with stdout and stderr setting to `PIPE` (the default value), the write end of the pipe doesn't get closed after the process is daemonized with the double-fork technique. It is likely an issue in FRR on how it launches a daemon process, but we can mitigate this in vyos-1x by changing the default values of `stdout` and `stderr` from `PIPE` to `None`. A `None` value causes the child process created by `Popen` to inherit stdout and stderr from its parent process.

During developing https://github.com/vyos/vyos-1x/pull/2179, I found `vyos.utils.process.call` could hang when starting an FRR daemon. Steps to produce this issue: ``` # ensure igmp protocol is disabled delete protocols igmp commit # enable igmp protocol, which will cause pimd to start set protocols igmp interface eth0 commit # hangs here ``` I found it hanged at `pipe = p.communicate(input, timeout)` (https://github.com/vyos/vyos-1x/blob/fc35434bfb0def50e5e492030451e035c80d153d/python/vyos/utils/process.py#L82) when `call(pimd_cmd)` is called at (https://github.com/vyos/vyos-1x/blob/fc35434bfb0def50e5e492030451e035c80d153d/src/conf_mode/protocols_igmp.py#L122). At the same time, `ps -ef | grep pimd` showed that pimd was `<defunct>`: ``` frr 68972 68968 0 06:52 pts/1 00:00:00 [pimd] <defunct> frr 68973 1 0 06:52 ? 00:00:00 /usr/lib/frr/pimd -d -F traditional --daemon -A 127.0.0.1 ``` By looking at this issue closer, I found it was similar to https://stackoverflow.com/questions/50646412/subprocess-becomes-defunct-communicate-hangs. Changing stdout and stderr from PIPE to None solved the issue: ``` call(f'/usr/lib/frr/pimd -d -F traditional --daemon -A 127.0.0.1', stdout=None, stderr=None) ``` It seems to me that when calling `call(f'/usr/lib/frr/pimd -d -F traditional --daemon -A 127.0.0.1')` with stdout and stderr setting to `PIPE` (the default value), the write end of the pipe doesn't get closed after the process is daemonized with the double-fork technique. It is likely an issue in FRR on how it launches a daemon process, but we can mitigate this in vyos-1x by changing the default values of `stdout` and `stderr` from `PIPE` to `None`. A `None` value causes the child process created by `Popen` to inherit stdout and stderr from its parent process.

During developing https://github.com/vyos/vyos-1x/pull/2179, I found `vyos.utils.process.call` could hang when starting an FRR daemon. Steps to produce this issue: ``` # ensure igmp protocol is disabled delete protocols igmp commit # enable igmp protocol, which will cause pimd to start set protocols igmp interface eth0 commit # hangs here ``` I found it hanged at `pipe = p.communicate(input, timeout)` (https://github.com/vyos/vyos-1x/blob/fc35434bfb0def50e5e492030451e035c80d153d/python/vyos/utils/process.py#L82) when `call(f'vtysh -d pimd -f {config_file}')`_cmd)` is called at (https://github.com/vyos/vyos-1x/blob/fc35434bfb0def50e5e492030451e035c80d153d/src/conf_mode/protocols_igmp.py#L1252). At the same time, `ps -ef | grep pimd` showed that pimd was `<defunct>`: ``` frr 68972 68968 0 06:52 pts/1 00:00:00 [pimd] <defunct> frr 68973 1 0 06:52 ? 00:00:00 /usr/lib/frr/pimd -d -F traditional --daemon -A 127.0.0.1 ``` By looking at this issue closer, I found it was similar to https://stackoverflow.com/questions/50646412/subprocess-becomes-defunct-communicate-hangs. Changing stdout and stderr from PIPE to None solved the issue: ``` call(f'vtysh -d pimd -f {config_file}'/usr/lib/frr/pimd -d -F traditional --daemon -A 127.0.0.1', stdout=None, stderr=None) ``` It seems to me that when calling `call(f'vtysh -d pimd -f {config_file}')`/usr/lib/frr/pimd -d -F traditional --daemon -A 127.0.0.1')` with stdout and stderr setting to `PIPE` (the default value), the write end of the pipe doesn't get closed after the process is daemonized with the double-fork technique. It is likely an issue in FRR on how it launches a daemon process, but we can mitigate this in vyos-1x by changing the default values of `stdout` and `stderr` from `PIPE` to `None`. A `None` value causes the child process created by `Popen` to inherit stdout and stderr from its parent process.