DHCP issues 2

[Simon]

Leslie Rhorer <lesrhorer at siliconventures.net> wrote:
> 
> On 6/2/2022 5:52 PM, Leslie Rhorer wrote:
>> On 6/2/2022 2:00 PM, Simon wrote:
>>> Leslie Rhorer <lesrhorer at siliconventures.net> wrote:
>>> 
>>>>      2. Stopping the service does not actually do anything.  The .pid file remains intact and the service remains in memory.  Having to manually delete the .pid file and manually kill the daemon is a pain, especially right now since I am setting things up and restarting the service a lot.
>>> That is easy to answer - it’s NOT a DHCP server issue, that’s a distro/packaging issue.
>>> Since I don’t use systemd, I can’t help further in terms of the startup/shutdown problems.
>> 
>>     I would be inclined to agree, except for two things:
>> 
>> 1.  Why is it happening on the secondary and not the primary? They are the same version of the same distro.
>> 
>> 2.  Why is dhcpd sending an exit code of 1?  That is why systemd thinks there is a failure.  Dhcpd (or any daemon) is supposed to send an exit code of 0.
> 
> 
>     I found the problem.  It was not a distro issue.  It was my error.  Before I wiped the OS, there was some sort of fatal error going on.  For testing purposes, I disabled IPv6 in the /etc/defaults/isc-dhcp-server file, but I accidentally neglected to comment out the INTERFACESv6 line.  This was causing dhcpd to issue an exit code of 1.  This not only caused the start option to report an error, but also was preventing the stop option from cleaning up the .pid file and terminating the daemon.  Before wiping the OS, I copied all the config files to a backup and restored them after the re-install.  This cleared whatever was causing the fatal issue, but retained the spurious error report.

You beat me to it - I was going to add that you really needed to sort out what was failing at start - and that really means seeing the logs because the server would have given a clue in the logs. One way to try and work around this would be to try and figure out exactly what command line was used to start the service and to try starting it manually from the command line (adding the “don’t background yourself” flag) - that way you could see what diagnostics were given.
If the service started but the process manager (systemd) thought it hadn’t, then on “stopping” the service, it looks like the service manager is doing nothing on the basis of “it’s not running so nothing to stop”.

Simon