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.