Hi, (i'm a )

I'm using mandrake 9.1 ProSuite, and I 'm setting up a server for DHCP.
But the dhcpd daemon will NOT start when I use DrakXservices. There is no error only dhcpd stop [failed] , dhcpd start [faild]. Webmin does't give any hints on what's wrong too.


This inmy /etc/dhcpd.conf file:


subnet 10.0.0.0 netmask 255.255.255.0
{
range 10.0.0.10 10.0.0.50;
default-lease-time 21600;
max-lease-time 43200;
}

This should work, according to most guides......

What the hell am I doing wrong????

PS: I've got 2 NICs in my machine....

Check out your system log file - in a console type one of these two (different logs) after trying to start the dhcpd daemon. Should be in the first one though:

tail /var/log/syslog
tail /var/log/messages

Or in Webmin, go to System then System Logs and you can select them there. Else, you can make dhcpd send all output to the error output by running:

dhcpd -d

instead. Hopefully actually having the error message will help you sort it out, otherwise post back. Note that daemons usually log their output to the syslog as they don't normally have a console running them (i.e. they'll be running on a "headless" server in a aircon room somewhere!).

HTH

I've just reinstalled the damn machine, because I didn't expect any answers anymore....

But I'll look again and try your sloution if this won't work..... if your solution doesn't work too i'll post back.

Feel free... just remember... you almost never have to reinstall a machine from scratch on Linux - it's almost always recoverable. Even if you can't boot up, you can pop in a rescue CD, and be back in your system!

I know the temptation... I used to do it when I first started with Linux a few years back but you soon learn the way...

I dont understand these output, so I hope you will help me......

[root@localhost dhcp]# tail /var/log/messages
Mar 10 22:50:06 localhost CROND[2662]: (mail) CMD (/usr/bin/python -S /var/lib/mailman/cron/gate_news)
Mar 10 22:50:09 localhost kernel: martian source 10.0.0.255 from 10.0.0.11, on dev eth1
Mar 10 22:50:09 localhost kernel: ll header: ff:ff:ff:ff:ff:ff:00:01:03:33:08:ec:08:00
Mar 10 22:50:09 localhost kernel: martian source 10.0.0.255 from 10.0.0.11, on dev eth1
Mar 10 22:50:09 localhost kernel: ll header: ff:ff:ff:ff:ff:ff:00:01:03:33:08:ec:08:00
Mar 10 22:50:09 localhost kernel: martian source 10.0.0.255 from 10.0.0.12, on dev eth1
Mar 10 22:50:09 localhost kernel: ll header: ff:ff:ff:ff:ff:ff:00:01:03:33:08:ec:08:00
Mar 10 22:50:09 localhost kernel: martian source 10.0.0.255 from 10.0.0.12, on dev eth1
Mar 10 22:50:09 localhost kernel: ll header: ff:ff:ff:ff:ff:ff:00:01:03:33:08:ec:08:00
Mar 10 22:50:57 localhost CROND[2665]: (mail) CMD (/usr/bin/python -S /var/lib/mailman/cron/qrunner)

This is the output from the terminal......

That doesn't look like it has anything to do with dhcpd - try:

tail /var/log/syslog

just after you run the dhcpd daemon. You should see something like:

Mar 10 22:50:09 localhost dhcpd: some error message here

Alternatively, try running the command

dhcpd -d

to log to the console.

Ie run dhcpd -d and got the output:



** You must add a ddns-update-style statement to /etc/dhcpd.conf.
To get the same behaviour as in 3.0b2pl11 and previous
versions, add a line that says "ddns-update-style ad-hoc;"
Please read the dhcpd.conf manual page for more information. **



I will edit my dhcpd.conf soon (tonight or tomorrow, it is now 11PM), and reply wether it works.

I got this, it looks good: thanks to YOU

Internet Software Consortium DHCP Server V3.0pl2
Copyright 1995-2003 Internet Software Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP
Wrote 0 leases to leases file.
Multiple interfaces match the same subnet: eth0 eth1
Multiple interfaces match the same shared network: eth0 eth1
Listening on LPF/eth1/00:10:22:fd:df:cd/10.0.0.0/24
Sending on LPF/eth1/00:10:22:fd:df:cd/10.0.0.0/24
Listening on LPF/eth0/00:01:03:33:08:ec/10.0.0.0/24
Sending on LPF/eth0/00:01:03:33:08:ec/10.0.0.0/24
Sending on Socket/fallback/fallback-net

Almost definitely will - I've seen this behaviour before. Remember about the syslog though - always handy!

Looks good - glad it worked