I have enabled the DHCP server using systemctl start dhcpd.service I have a pretty simple dhcp.conf which looks like this: ************************ ddns-update-style interim; ignore client-updates;
subnet 192.168.2.0 netmask 255.255.255.0 { option routers 192.168.2.1; option subnet-mask 255.255.255.0; option domain-name-servers 151.197.0.38, 199.45.32.38; option ip-forwarding off; range dynamic-bootp 192.168.2.100 192.168.2.254; default-lease-time 21600; max-lease-time 43200; } ************************** If I run the services command, the GUI doesn't show DHCPD as available, much less running, but I don't know if this is just part of the new sysctl way of doing things. I tired connecting to the server using omshell, and I get the following:
# omshell
connect
../../../../lib/isc/unix/socket.c:891: epoll_ctl(DEL), 5: Bad file descriptor ../../../../lib/isc/unix/socket.c:891: epoll_ctl(DEL), 5: Bad file descriptor dhcpctl_connect: no more
Can anyone give me an idea where I might go to troubleshoot this?
On 8/11/2011 5:28 PM, Claude Jones wrote:
I have enabled the DHCP server using
systemctl start dhcpd.service ..........snip the rest..........
I left out the main point, the nature of the problem. The server doesn't seem to work, and addresses are not being handed out. This had been working several months back but I haven't used it in a long time and just discovered it no longer worked. I've swapped out cables and restarted the machine just to make sure it wasn't something like that...
On Thu, 11 Aug 2011 17:59:55 -0400 Claude Jones wrote:
I left out the main point, the nature of the problem. The server doesn't seem to work, and addresses are not being handed out.
You might try restarting it after the system is well and truly up. I have problems with lots of network based services not working when I let systemd start them, but if I put code in /etc/rc.local to background a command to sleep a few seconds and restart the service, everything seems to work fine. (The ypbind service, nfs mounts, etc. all suffer from this problem).
My theory is that systemd thinks it is waiting for the network to be "up", but whatever is telling the network is up is really lying.
On 08/11/2011 06:42 PM, Tom Horsley wrote:
On Thu, 11 Aug 2011 17:59:55 -0400 Claude Jones wrote:
I left out the main point, the nature of the problem. The server doesn't seem to work, and addresses are not being handed out.
You might try restarting it after the system is well and truly up. I have problems with lots of network based services not working when I let systemd start them, but if I put code in /etc/rc.local to background a command to sleep a few seconds and restart the service, everything seems to work fine. (The ypbind service, nfs mounts, etc. all suffer from this problem).
My theory is that systemd thinks it is waiting for the network to be "up", but whatever is telling the network is up is really lying.
Has anyone got a script which will 'restart' all services which are targetted to be started at boot - that way we can run the script by hand in rc.local and make sure anything that systemd broke gets restarted properly ...
Better would be to somehow figure out (outside of systemd) which services are actually not really running - and restart those.
Please don't say replace systemd with initd ... :-)
thanks.
On Thu, 11 Aug 2011 19:26:50 -0400 Genes MailLists wrote:
Better would be to somehow figure out (outside of systemd) which services are actually not really running - and restart those.
Unfortunately, most of the services I have problems with appear to be "really running", they just don't work right unless I restart them after the boot :-(.
On 08/11/2011 07:54 PM, Tom Horsley wrote:
On Thu, 11 Aug 2011 19:26:50 -0400 Genes MailLists wrote:
Better would be to somehow figure out (outside of systemd) which services are actually not really running - and restart those.
Unfortunately, most of the services I have problems with appear to be "really running", they just don't work right unless I restart them after the boot :-(.
Hmm ok ... how about the restart all desired services - probably what would happen after a glibc update for example ... maybe systemd has a restart all systemctl restart All.units or something
On Thursday, August 11, 2011, Tom Horsley wrote:
I left out the main point, the nature of the problem. The server doesn't seem to work, and addresses are not being handed out.
You might try restarting it after the system is well and truly up
I did try that, actually. But, I didn't stop first, then restart. I just issued the commands I cited in my original post. Anyone have any familiarity with the omshell command and it's readout? The command is cited right in the DHCP section of the Fedora 15 documentation - I read the man page for it but it's a bit difficult to grok...
On 08/11/2011 10:44 PM, Claude Jones wrote:
Anyone have any familiarity with the omshell command and it's readout? The command is cited right in the DHCP section of the Fedora 15 documentation - I read the man page for it but it's a bit difficult to grok...
Probably a bit obvious - but did you look in /var/log/messages for any warnings/errors - perhaps you have a config file problem.
On Thu, Aug 11, 2011 at 6:00 PM, Genes MailLists lists@sapience.com wrote:
On 08/11/2011 07:54 PM, Tom Horsley wrote:
On Thu, 11 Aug 2011 19:26:50 -0400 Genes MailLists wrote:
Better would be to somehow figure out (outside of systemd) which services are actually not really running - and restart those.
This little script will check to see if the PID systemd thinks is supposed to be the main daemon is running and restart it if not: https://gist.github.com/1141585
Unfortunately, most of the services I have problems with appear to be "really running", they just don't work right unless I restart them after the boot :-(.
Hmm ok ... how about the restart all desired services - probably what would happen after a glibc update for example ... maybe systemd has a restart all systemctl restart All.units or something
Pull a couple conditionals out of the above script, and you can restart all services: https://gist.github.com/1141591
(I don't think you want to restart all *units*, as that would entail unmounting and mounting!)
Of course, ideally you want to figure out what's really gone wrong and forego all this band-aid nonsense, but it might help you out in the interim.
-T.C.
On Thursday, August 11, 2011, Genes MailLists wrote:
On 08/11/2011 10:44 PM, Claude Jones wrote:
Anyone have any familiarity with the omshell command and it's readout? The command is cited right in the DHCP section of the Fedora 15 documentation - I read the man page for it but it's a bit difficult to grok...
Probably a bit obvious - but did you look in /var/log/messages for any warnings/errors - perhaps you have a config file problem.
Thanks to you, and to all, for the responses. I had no time today to deal with this today, but I will pursue this again as soon as time permits - and, to answer your specific suggestion, I did not look at logs yet - I did notice a message during boot-up that DHCP was starting
On Thursday, August 11, 2011, Genes MailLists wrote:
On 08/11/2011 10:44 PM, Claude Jones wrote:
Anyone have any familiarity with the omshell command and it's readout? The command is cited right in the DHCP section of the Fedora 15 documentation - I read the man page for it but it's a bit difficult to grok...
Probably a bit obvious - but did you look in /var/log/messages for any warnings/errors - perhaps you have a config file problem.
Well, I logged in remotely and I think I've found my problem - this entry appears in the kernel log:
08/11/11 09:04:40 PM dhcpd[922] Not configured to listen on any interfaces!
On Saturday, August 13, 2011 12:34:35 AM Claude Jones wrote:
Probably a bit obvious - but did you look in
/var/log/messages for any warnings/errors - perhaps you have a config file problem.
Well, I logged in remotely and I think I've found my problem - this entry appears in the kernel log:
08/11/11 09:04:40 PM dhcpd[922] Not configured to listen on any interfaces!
Gene: Your stating the obvious led me to the answer. It turns out I had misconfigured the DHCPDARGS=eth# statement in /etc/sysconfig/dhcpd giving it the wrong (and non- existent) interface number. Found this lead on the first hit after googling that error...
Thanks to all who had suggestions
-
Claude Jones -
Genes MailLists -
T.C. Hollingsworth -
Tom Horsley