rc.dhcpd has an odd error.
 

This hasn't come up because who the devil restarts their dhcpd while the system is running? (At least that's my story and I'm sticking to it.)

It turns out I've been doing that while attempting to fix a dynamic DNS issue. The issue comes about because the dhcpd binary looks for the pid file and won't start if it finds one.

For example, the first time you run restart:

...but the second time you run that command, you get...

There are a couple of ways to fix the issue:

1. You can make "--no-pid" a default DHCPD_OPTIONS value, so there won't be a pid file to check
2. You can add "rm /var/run/dhcpd.pid" in the stop() block

I don't have an opinion upon which option is superior. The stop() bit of the script doesn't bother to look at /var/run/dhcpd.pid but instead just kills everything named dhcpd.

Derp. That's running Slackware64 15.0 that's up-to-date as of 4:40AM CDT this morning.

My first step is, trace it with

Maybe you replied to the wrong thread; I know what the problem is.

When you want to stop a service:
if the process/service is not running (stopped already) nothing will happen, therefore the pidfile will not be checked and removed.
if the process/service is running it should be terminated and also the pidfile(s) should be removed.

An existing pidfile without running process means incorrect termination or a bug in the software somewhere. The fix is: remove the pidfile manually or find/fix/report the bug. Don't add --no-pid as it will probably make things worse (because the pidfile is still there).
And I wouldn't add force remove to the stop function (it looks like an ugly workaround for me), but I would rather try to terminate it properly.

I don't use network-manager and I replaced slackware's stock networking scripts with my own, but I find dhcpcd manages its pidfiles itself if you issue the 'dhcpcd -k' or 'dhcpcd -x' commands to stop it.

One caveat is that the pidfile name used is somewhat dynamic and can change depending on what options were provided to dhcpcd when you started it: 'dhcpcd -P' can help with that though.

dhcpcd != dhcpd != httpd

:doh: :redface: :banghead: That was my (really stupid) goof.

But my suggestion remains. Running "sh -vx /etc/rc.d/rc.[service]" in that directory, to examine what's going on, is the best place to start. It might be simple timing, so a simple fix; or maybe something worse, especially when it's wrong or suspicious. But the first step is to gather that extra, unusual information.

Oops! :redface:

By the way, there is actually no /etc/rc.d/rc.dhcpd in Slackware. You have probably copied it from usb-and-pxe-installers/README_PXE.TXT like I did when I used PXE to install Slackware.

I noticed this in https://www.isc.org/dhcp/:
This is the new one: https://www.isc.org/download/#Kea
In slackbuilds.org: https://slackbuilds.org/repository/15.0/network/kea/

You are absolutely correct about rc.dhcpd. I guess I pulled it in a loooong time ago on one of my Slackware machines and cloned it to the others I run.

The tell (had I been paying attention) would have been that it was launched via rc.local versus a block in rc.M.

I've never done a real PXE boot on my networks (I did look at it more than a decade ago), so I probably pulled rc.dhcpd out of one of the /usr/doc/ files that had it.

(I hadn't looked for kea in slackbuilds.org; I rather assumed that Slackware itself would pull that in. For all I know, it's in -current.)

Thank you very much, Petri Kaukasoina, for clarity. I apologize for the noise here.

Me reading this thread: