Hello,
I have analyzed the behavior of valet stop in Valet-Linux version 2.4.4 and identified a bug related to DNS configuration reversion upon shutdown.
Basic info
| Distro (Name and version) |
PHP Version |
Valet version |
| Linux Mint 22.2 |
8.3 |
2.4.4 |
What is the problem?
The valet-dns stop function does not revert the system's DNS configuration after shutting down DnsMasq. This failure to restore the original /etc/resolv.conf file causes a complete loss of external DNS resolution and Internet connectivity.
What was supposed to happen?
When executing valet stop, the system is expected to stop services (Nginx, PHP-FPM, DnsMasq) and, critically, the valet-dns stop script should revert the change to /etc/resolv.conf. This means restoring the original DNS file from the backup (/etc/resolv.conf.bak) and allowing the Network Manager/Systemd-resolved to take back control of public DNS resolution.
What actually happened?
valet stop shuts down DnsMasq and other services, as expected.
- The
valet-dns stop script fails to execute the necessary reversion logic.
- The
/etc/resolv.conf file remains a symlink pointing to the Valet-managed file ($VRESOLV).
Consequence: Since DnsMasq (which listens on 127.0.0.1) is inactive, the system attempts to resolve all domain names using an inactive local resolver, resulting in a complete loss of Internet connectivity.
How to reproduce this?
- Install Valet-Linux v2.4.4 on Linux Mint 22.2.
- Ensure Valet is running.
- Execute
valet stop.
- Attempt to resolve a public address (e.g.,
ping google.com).
What is the solution?
The fix is likely needed within the valet-dns stop script to ensure the backup file (/etc/resolv.conf.bak) is correctly restored before the script exits.
Sources
Logs captured immediately after valet stop:
tjloq@tjloq-LOQ-15IAX9E:~$ valet start
Restarting php8.3-fpm...
Restarting nginx...
Restarting dnsmasq...
Valet services have been started.
tjloq@tjloq-LOQ-15IAX9E:~$ valet stop
Stopping php8.3-fpm...
Stopping nginx...
Stopping dnsmasq...
Valet services have been stopped.
tjloq@tjloq-LOQ-15IAX9E:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 28 out 27 21:31 /etc/resolv.conf -> /opt/valet-linux/resolv.conf
tjloq@tjloq-LOQ-15IAX9E:~$ ping -c 3 google.com
ping: google.com: Name or service not known
tjloq@tjloq-LOQ-15IAX9E:~$ systemctl status dnsmasq
○ dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; enabled; preset: >
Active: inactive (dead) since Mon 2025-10-27 22:39:03 -03; 28s ago
Duration: 5.414s
Process: 12532 ExecStartPre=/usr/share/dnsmasq/systemd-helper checkconfig (>
Process: 12538 ExecStart=/usr/share/dnsmasq/systemd-helper exec (code=exite>
Process: 12544 ExecStartPost=/usr/share/dnsmasq/systemd-helper start-resolv>
Process: 12805 ExecStop=/usr/share/dnsmasq/systemd-helper stop-resolvconf (>
Main PID: 12543 (code=exited, status=0/SUCCESS)
CPU: 55ms
Oct 27 22:38:58 tjloq-LOQ-15IAX9E dnsmasq[12543]: read /etc/hosts - 8 names
Oct 27 22:38:58 tjloq-LOQ-15IAX9E resolvconf[12551]: Dropped protocol specifier>
Oct 27 22:38:58 tjloq-LOQ-15IAX9E resolvconf[12551]: Failed to set DNS configur>
Oct 27 22:38:58 tjloq-LOQ-15IAX9E systemd[1]: Started dnsmasq.service - dnsmasq>
Oct 27 22:39:03 tjloq-LOQ-15IAX9E systemd[1]: Stopping dnsmasq.service - dnsmas>
Oct 27 22:39:03 tjloq-LOQ-15IAX9E resolvconf[12809]: Dropped protocol specifier>
Oct 27 22:39:03 tjloq-LOQ-15IAX9E resolvconf[12809]: Failed to revert interface>
Oct 27 22:39:03 tjloq-LOQ-15IAX9E dnsmasq[12543]: terminated upon receiving signal TERM
Oct 27 22:39:03 tjloq-LOQ-15IAX9E systemd[1]: dnsmasq.service: Deactivated succ>
Oct 27 22:39:03 tjloq-LOQ-15IAX9E systemd[1]: Stopped dnsmasq.service - dnsmasq>
Hello,
I have analyzed the behavior of
valet stopin Valet-Linux version 2.4.4 and identified a bug related to DNS configuration reversion upon shutdown.Basic info
valet --version): 2.4.4valet fixandvalet installafter updating and before submitting my issue/feature.What is the problem?
The
valet-dns stopfunction does not revert the system's DNS configuration after shutting down DnsMasq. This failure to restore the original/etc/resolv.conffile causes a complete loss of external DNS resolution and Internet connectivity.What was supposed to happen?
When executing
valet stop, the system is expected to stop services (Nginx, PHP-FPM, DnsMasq) and, critically, thevalet-dns stopscript should revert the change to/etc/resolv.conf. This means restoring the original DNS file from the backup (/etc/resolv.conf.bak) and allowing the Network Manager/Systemd-resolved to take back control of public DNS resolution.What actually happened?
valet stopshuts down DnsMasq and other services, as expected.valet-dns stopscript fails to execute the necessary reversion logic./etc/resolv.conffile remains a symlink pointing to the Valet-managed file ($VRESOLV).Consequence: Since DnsMasq (which listens on
127.0.0.1) is inactive, the system attempts to resolve all domain names using an inactive local resolver, resulting in a complete loss of Internet connectivity.How to reproduce this?
valet stop.ping google.com).What is the solution?
The fix is likely needed within the
valet-dns stopscript to ensure the backup file (/etc/resolv.conf.bak) is correctly restored before the script exits.Sources
Logs captured immediately after
valet stop: