In order to analyze the issue, I tried to remove the /etc/resolv.conf in the normal mode and traced the syslog if any systemd service restored the file. What I observed is NM will go through this line of writing DNS, and reported the warning from calling /etc/resolvconf/update.d/libc:
<info> [1516604239.0578] dns-mgr: Writing DNS information to /sbin/resolvconf
warning "/etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf"
I'm thinking the /etc/resolv.conf will be dynamically recreated, and then NM moved on to finish its service (so NM is able to keep alive). However, under the recovery mode, the NM can't normally start its service and exit due to catch the signal SIGTERM (not sure if it's related to nm_dispatcher). So seems like we have two problems here:
1. why does NM fail to start
2. why does NM not try to call /etc/resolvconf/update.d/libc to restore the file in the recovery mode
Giving the working note what I'm doing currently:
In order to analyze the issue, I tried to remove the /etc/resolv.conf in the normal mode and traced the syslog if any systemd service restored the file. What I observed is NM will go through this line of writing DNS, and reported the warning from calling /etc/resolvconf /update. d/libc:
<info> [1516604239.0578] dns-mgr: Writing DNS information to /sbin/resolvconf /resolv. conf"
warning "/etc/resolv.conf is not a symbolic link to /run/resolvconf
I'm thinking the /etc/resolv.conf will be dynamically recreated, and then NM moved on to finish its service (so NM is able to keep alive). However, under the recovery mode, the NM can't normally start its service and exit due to catch the signal SIGTERM (not sure if it's related to nm_dispatcher). So seems like we have two problems here:
1. why does NM fail to start /update. d/libc to restore the file in the recovery mode
2. why does NM not try to call /etc/resolvconf