The PC in question is a CuBox-i mini-pc. Since this PC doesn't have a battery, everytime the PC reboots the hardware clock is reset back to the same date every time, which is "2014-07-08 00:00".
I have NTP configured to get the current date and time from our NTP server, which does work eventually once the network comes up. Once the network is up, the NTP daemon runs and fixes the date and time.
However, I believe once NTP runs and changes the date and time, the DHCP lease timeout is reached (*14400 I believe). And because the time jumps ahead so far, it thinks the DHCP lease has timed-out and it gets a new IP Address. So within about a couple minutes of powering on, or rebooting the PC, it renews its DHCP Address and gets a new/2nd address.
I was wondering if maybe there is a way I can write the current system date and time so when it reboots, it doesn't think its 2014... Is anything like that possible?
You could try using the date command to write the date to a file at shutdown and letting date set the date to what was recorded in that file at boot time before the network comes up.
You could use a @reboot cron job to read the date at boot time, but of course that's only effective when the cron daemon is started, and you need something else to write the file before shutting down.
As you want to tightly couple it to the DHCP daemon as much as possible, not a great solution, but is modifying the dhcpd start / stop script an option? You could also just run ntp to update the time before it starts the DHCP daemon.
Changing the order services start in could be another option, but there's no guarantee that ntdp will update the time before it gets to dhcpd.
(edit, after Bakunin's reply): I presume also that assigning static address(es) to the client(s) is not an option?
Scott's idea is valid anyway, but if i remember TCP/IP correctly (my copy of TCP/IP Illustrated is not within reach right now) the DHCP server manages lease times, not the client.
You can also configure the DHCP server to always give the same IP-address to this client, because DHCP is the supersset of the older bootp -protocol, which did exactly that. Clients are identified by the MAC-address(es) of the interface(s) requiring an address. This way it doesn't matter if the address is requested once or twice.
Hey Guys, thanks again for the replies. Much appreciated!
All good ideas. I do have the ability to do any of those that you suggested, as I have access to the DHCP server(s) that we run. But, these little mini-PCs are located in each of our branch locations, and their local Router/Switches are running as their DHCP servers, so that would be a lot of editing I would need to do in each location in order to statically assign the IP Address. And occasionally I need them to ship the PC back as it runs off an SDCard and gets all screwy, so I need to re-image the SDCard. When this happens I usually ship them a new one before they ship back the current one, so the MAC Address changes from time to time.
I guess I could modify each CuBox PC to assign its own address statically, that's another good option...
The date/time thing on these little PCs is annoying though. Not only does it have the DHCP thing going on, all the log's timestamps are all screwy inside the log files, as well as their file's modification times. It's like every file was modified 7-8-2014 or whatever the current day's date is. When looking at the boot log file, or messages, etc... You can see at boot it shows "7-8-2014 00:xx" and then during the boot you see NTP start, (*and then the Network services) which corrects the time. Like this below:
2014-07-08T00:00:12.180148-04:00 CuBox-PC2 ntpd[515]: ntpd 4.2.6p5@1.2349-o Tue Jul 22 08:39:03 UTC 2014 (1)
2014-07-08T00:00:12.186116-04:00 CuBox-PC2 ntpd[516]: proto: precision = 0.666 usec
2014-07-08T00:00:12.192294-04:00 CuBox-PC2 ntpd[516]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
2014-07-08T00:00:12.195052-04:00 CuBox-PC2 ntpd[516]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
2014-07-08T00:00:12.208862-04:00 CuBox-PC2 ntp[487]: Starting network time protocol daemon (NTPD)..done
2014-07-08T00:00:12.219279-04:00 CuBox-PC2 systemd[1]: Started LSB: Network time protocol daemon (ntpd).
2014-07-08T00:00:12.221496-04:00 CuBox-PC2 systemd[1]: Starting System Time Synchronized.
2014-07-08T00:00:12.227680-04:00 CuBox-PC2 ntpd[516]: Listen and drop on 1 v6wildcard :: UDP 123
2014-07-08T00:00:12.231513-04:00 CuBox-PC2 ntpd[516]: Listen normally on 2 lo 127.0.0.1 UDP 123
2014-07-08T00:00:12.239589-04:00 CuBox-PC2 ntpd[516]: Listen normally on 3 lo ::1 UDP 123
2014-07-08T00:00:12.249842-04:00 CuBox-PC2 ntpd[516]: peers refreshed
2014-07-08T00:00:12.252038-04:00 CuBox-PC2 ntpd[516]: Listening on routing socket on fd #20 for interface updates
................
......cut.....
................
2014-07-08T00:00:22.035161-04:00 CuBox-PC2 systemd[1]: Starting Network Manager Script Dispatcher Service...
2014-07-08T00:00:22.122828-04:00 CuBox-PC2 dbus[405]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
2014-07-08T00:00:22.129075-04:00 CuBox-PC2 systemd[1]: Started Network Manager Script Dispatcher Service.
2014-07-08T00:00:24.438413-04:00 CuBox-PC2 ModemManager[410]: <info> Creating modem with plugin 'Generic' and '1' ports
2017-10-12T12:50:42.697027-04:00 CuBox-PC2 systemd[670]: Time has been changed
2017-10-12T12:50:42.702891-04:00 CuBox-PC2 systemd[640]: Time has been changed
2017-10-12T12:50:42.708762-04:00 CuBox-PC2 systemd[1]: Time has been changed
2017-10-12T12:50:42.959656-04:00 CuBox-PC2 systemd[1]: mgetty.service: main process exited, code=exited, status=20/n/a
I guess it's not really a huge problem, its just gotten very annoying. So maybe trying to get the date to write to a file and then write it back at boot-up (*maybe as soon as the shell starts) would kill a few birds with one stone...