On Tue, 19 Sep 2017, Chris wrote:
On Wed, 2017-09-20 at 00:40 +0100, Martin Gregorie wrote:
On Tue, 2017-09-19 at 16:44 -0500, Chris wrote:
Thanks Martin, here's what I get, it appears to not be running.
sudo systemctl stop dnsmasq
[sudo] password for chris:
Failed to stop dnsmasq.service: Unit dnsmasq.service not loaded.
OK, that makes sense
sudo systemctl disable dnsmasq
Failed to execute operation: No such file or directory
That's interesting: I've never seen that before:
[snip..]
It would be interesting to know what 'systemctl status' shows on your
system, though its quite possible it looks similar to what 'systemctl
disable' showed. I can only guess that your system is a transitional
systemd setup, i.e. systemctl is used for service management but some
services (dnsmasq for one) are still running under the old systemV
init
scripts. Fedora installations used to work that way for some
services,
but that was a few versions ago (F21 or 22 at the latest).
Martin
Hi Martin, here's what I see:
sudo systemctl status dnsmasq
[sudo] password for chris:
● dnsmasq.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
chris@localhost:~$ sudo systemctl enable dnsmasq
Failed to execute operation: No such file or directory
chris@localhost:~$ sudo systemctl status dnsmasq
● dnsmasq.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
I then installed dnsmasq (apparently it wasn't installed)
Results are here - https://pastebin.com/MRR4NCMp
dnsmasq was already there (see your own previous posts) just not put there via
the "apt" package management system. Thus "apt" didn't know about the rogue
dnsmasq process, and it failed to start the newly installed one.
(as the rogue dnsmasq process was already there, running, and bound to the DNS
socket).
So now you have -two- dnsmasq kits, one installed by "apt" and managed thru the
"systemctl" tools, and another one that somebody put there which is outside the
realm of "apt" & "systemctl" (thus they don't know how to manange it).
You should really pick one method of installing/managing software and stick with
it.
This is similar to the mess you get when you mix CPAN with yum/yast/rpm/apt for
installing Perl modules.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
