Comment 13 for bug 1682637

Revision history for this message
Woodrow Shen (woodrow-shen) wrote :

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
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