Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
I was investigating the time drift on my DNS-323 and I discovered some jobs qued
with the atd daemon, but I can't figure out why these jobs are there?
After I reboot the system I can run
#atq
1 2007-01-12 01:59 a root
2 2007-01-12 01:59 a root
Which reveals two jobs in the que
# ls -la /var/spool/at
drwxr-xr-x 2 root root 1024 Jan 11 22:31 .
drwxr-xr-x 4 root root 1024 Dec 26 2005 ..
-rw-r--r-- 1 root root 6 Jan 11 22:31 .SEQ
-rwx------ 1 root root 254 Jan 11 22:31 a0000101293077
-rwx------ 1 root root 254 Jan 11 22:31 a0000201293077
Each of these jobs consists of an identical script with is robustly written to run: '/usr/bin/daylight 1'
# more /var/spool/at/a0000101293077
#!/bin/sh
# atrun uid=0 gid=0
# mail root 0
umask 22
USER=root; export USER
HOME=/; export HOME
PATH=/usr/bin:/bin:/usr/sbin:/sbin; export PATH
PWD=/; export PWD
cd / || {
echo 'Execution directory inaccessible' >&2
exit 1
}
/usr/sbin/daylight 1
# more /var/spool/at/.SEQ
00002
I could not find any reference to daylight.c in any of the GPL sources provided on the D-Link site,
nor could I find any mention of 'daylight' (script or binary) in a google search.
Does anyone know what this executable is supposed to do? or know where the source might come from?
Now, the REALLY curious thing....
Each day the que multiplies by two. So, the next day I have 4 jobs in my que, then 8, then 16, then 32...
All the jobs are the exact same script to run: '/usr/bin/daylight 1'
So, tonight at 1:59am my DNS will run: '/usr/bin/daylight 1' thirty-two times!!!
I'm not sure what process is creating the atd jobs or why the number of jobs are increasing??
Anyone have any ideas?
Offline
mig wrote:
...
Does anyone know what this executable is supposed to do? or know where the source might come from?
...
I'm not sure what process is creating the atd jobs or why the number of jobs are increasing??
Anyone have any ideas?
Ideas, yes. Answers no. A fair guess is that "daylight" is some tool used to implement daylight savings. Especially since this script is executed at 2 am according to your findings.
From your findings I'd guess that the last thing the "program" does is to inject another copy of itself by issuing at/atrun/batch. I also guess that, for some reason, the current program is not removed from the que upon execution.
Have you checked if "daylight" is a binary or a script? I don't have access to my unit atm but will check later today. If your findings are correct then we have some kind of "leak" here which will cause the unit to degrade, and this quite quickly.
After a month you will have 1'073'741'824 entires in your atq, :-)
Would be nice to see of someone can confirm this behaviour. Are you on 1.01 or 1.02?
Offline
Could this be the cause to why my DNS-323 FW1.02 stops working after 7-10 days?
..and yes, I've got Daylight Savings enabled and set to EU.
Last edited by MiK (2007-01-16 11:57:21)
Offline
Apskaft wrote:
Have you checked if "daylight" is a binary or a script? I don't have access to my unit atm but will check later today.
Did some more research on this. The file is definitely related to daylight savings and the file is binary. I didn't have dayligh savings enabled and my atq was empty. So was my /usr/sbin/DAY_LIGHT. When I enabled daylight savings (EU) the file DAY_LIGHT was populated with "/usr/sbin/daylight 2" and all of a sudden I had two entries in my at-queue?!? (Why two, one would be enough?!?)
Next step was to set it to US, and the file got populated with "/usr/sbin/daylight 1". Now, all of a sudden, I have four (!!!) entries in my at-queue.
The file "daylight" has a few strings which basicly tells us how it operates:
/tmp/GetTimeServerFinish /usr/sbin/TimeID atrm %s rm -f /usr/sbin/TimeID rm -f /usr/sbin/DAY_LIGHT 01:59 %d/ /usr/sbin/DAY_LIGHT /usr/sbin/daylight %c at -f /usr/sbin/DAY_LIGHT atq > /usr/sbin/at_log /usr/sbin/at_log rm -f /usr/sbin/at_log
Appearently there are issues with their implementation when it populates the at-queue. IMHO, at is not the tool to use here - instead this would be a typical cron job. But I guess cron is not supported so they invented their own poor-mans-cron.
With these findings and what's said in entries above, I'd reccomend you all to disable daylight savings, telnet to your box and issue a atd for each entry in your atq.
The following is obvously corrupt (read: a bug) in this file (daylight):
* Duplicates entries at each execution, every night at 01.59 (2-4-8-16-32-64-128-256-512-1024-4096-...)
* Does not clean at-queue when disabling daylight savings
(maybe it does that at 01:59 since DAY_LIGHT is emptied, and this to at -f failure.....test may show)
Let's hope that MiK's device stays up for more than 7-10 days when atq is cleaned....
Oh....btw...it'd be quite easy/fun to create a fun_plug which enables a workaround for this bug. Just add an entry to at-queue (at -f daylight_bugfix.sh) which calls a script that every day at 3 am which cleans the duplicates in the at-queue and then inserts itself into the at-queue again.
I'd look something like this (WARNING - Not tested):
#!/bin/sh # # Empy at-queue # /usr/sbin/atrm -a # # Re-Insert daylight savings entries: Note, due to bug they're duplicated # /usr/sbin/at -f /usr/sbin/DAY_LIGHT 2am tomorrow # # Remove the errornous duplicate # /usr/sbin/atrm 2 # # Re-insert the bugfix for tomorrow # /usr/sbin/at -f /mnt/HD_a2/daylight_bugfix.sh 3am tomorrow
...and file that one with the bug-report to D-Link.....
HTH/Apan
Offline
Thanks for the responses and insight. I've discovered a few more things about this problem...
First a quick note on the script, the command '/usr/sbin/atrm -a' is not supported.
I rebooted the system and removed the two jobs in the queue with
#/usr/sbin/atrm 1
#/usr/sbin/atrm 2
If I use the command:
#/usr/sbin/daylight 1 (I have DST set to US, firmware v1.02)
I get TWO jobs in the atd queue
# atq
3 2007-01-17 01:59 a root
4 2007-01-17 01:59 a root
I cleared the atd queue and created a file /tmp/if which contained a single line '/sbin/ifconfig'
when I used the command
#at -f /tmp/if 22:23 today
a single atd job was created, after 22:23 the job was remove from the queue.
This shows the problem is with the '/sbin/daylight' binary and not the atd (not sure if that is good news or bad?)
One more thing, cron is supported on the DNS-323
using the command
# more /var/spool/cron/crontabs/root
32 2 * * * /usr/sbin/rtc -s
30 2 2 * * /usr/sbin/rtc -c
This shows there are two rtc jobs that execute periodically.
Offline
mig wrote:
One more thing, cron is supported on the DNS-323
using the command
# more /var/spool/cron/crontabs/root
32 2 * * * /usr/sbin/rtc -s
30 2 2 * * /usr/sbin/rtc -c
This shows there are two rtc jobs that execute periodically.
First job, executed every night at 2:32. Second job, executed at 2:30 on the 2nd every month. I'd guess that rtc stands for Real Time Clock and that these tasks contacts the configured NTP server. A fair guess, why they have two, is one is a "quick" check and the other is a more precise variant. Don't know much about NTP and rfc1305 is quite complex.....
Once again, is rtc binary or script (I guess binary).
Would be interesting to see an ethereal trace between 02:30 and 02:32 on the 2'nd.....
As crontab is available, it's odd the way they implemented realtime the way they did. A simple entry in the crontab would've been enough:
59 01 * * * /usr/sbin/daylight 1 (or 2)
How about the "Download Scheduler" - is it using at or cron for it's periodic jobs?
Offline
Apskaft wrote:
Once again, is rtc binary or script (I guess binary).
Binary:
# # rtc -h
rtc - query and set the hardware clock (RTC)
Usage: rtc [function]
Functions:
-h show this help
-r read RTC time and print it
-w read time from system and write to rtc(SYS -> RTC)
-s read time from rtc and write to sys(RTC -> SYS)
-c increase RTC 227 sec. each month
-d set rtc and system time to default time 2005/01/01 00:00:00
So, every night the system clock is aligned to the hardware clock (rtc) and once a month the harware clock is increased with 227 seconds.....why.....hwbug....drifting?
About the crontabs, my root:
# # cat root
32 2 * * * /usr/sbin/rtc -s
30 2 2 * * /usr/sbin/rtc -c
*/10 * * * * /usr/sbin/getdhcp&
EDIT: */10 makes you wonder since my lease time is set to 1440 minutes. Makes you wonder if getdhcp works unconditionally and renews every 10'th minute or if it actually checks the lease time.....odd.
...makes you wonder which process that handles scheduled downloads....../web/webs?!?
Last edited by Apskaft (2007-01-17 20:20:50)
Offline
I submitted the daylight script bug to D-Link tech support and I got at very positive response..
Your Case ID is DLK398288483.
Date of Reply: 1/17/2007
Products: DNS-323
Operating System: Windows XP Pro
Mig
Thank you for pointing this out I will be testing this and forward my finds to the product manager for a firmware fix.
Sincerely,
Eric French
D-Link Technical Support
Offline