systemd & date for manual setting of clock


19 posts
by grimpirate » Thu Nov 01, 2012 2:04 am
KouChat is a Java program I make use of to communicate over LAN between computers (makes it easy to transfer files and such). Unfortunately, without modifying the source it throws an error that refuses to let the program start due to the system time being set to the Unix epoch. Probably due to a numerical overflow oversight by the author. Unfortunately, I don't always have internet access so the time doesn't get properly set. I'd like to be able to launch this program when I simply have the varied computers on LAN. To do this I could just manually set an arbitrary date using the "date -s" command each time I login. That's a bit tedious, I'd prefer to do this on startup/shutdown automatically. I came up with the following solution, but it doesn't seem to work appropriately. I create a folder "systemd" within my user's home folder. Within it are two bash scripts, two systemd services, and a file that contains a time stamp: raspi-store, raspi-restore, raspi-store.service, raspi-restore.service, and time.stamp, respectively.

The shell scripts are as follows:
/home/tron/systemd/raspi-store
Code: Select all
#!/bin/sh

date -R > /home/tron/systemd/time.stamp

/home/tron/systemd/raspi-restore
Code: Select all
#!/bin/sh

date -s "`cat /home/tron/systemd/time.stamp`"

Both scripts work just fine (chmodded to 0755), when I execute them as root or using sudo. The services are as follows:

/home/tron/systemd/raspi-store.service
Code: Select all
[Unit]
Description=Store RasPi time
DefaultDependencies=no
Before=shutdown.target

[Service]
Type=oneshot
ExecStart=/home/tron/systemd/raspi-store
StandardOutput=syslog

/home/tron/systemd/raspi-restore.service
Code: Select all
[Unit]
Description=Restore RasPi time
DefaultDependencies=no
After=sysinit.target
Before=shutdown.target
Conflicts=shutdown.target

[Service]
Type=oneshot
ExecStart=/home/tron/systemd/raspi-restore
StandardOutput=syslog

In /usr/lib/systemd/system/ I created two symlinks to the services in my /home/tron/systemd folder. When I issued systemctl daemon-reload, and then did systemctl start raspi-store and systemctl raspi-restore, the services both executed just fine.

The problem occurs when I try to execute systemctl enable raspi-store or systemctl enable raspi-restore so that I can have the services load on boot. I forget the exact error that's issued, but it's something about a failed method called. The idea here is to use two systemd services, one on startup and one on shutdown, to restore and store the last good time, respectively. The services were modeled using alsa-store.service and alsa-restore.service as a reference. Any ideas why this is failing?
Posts: 38
Joined: Fri Oct 19, 2012 6:16 pm
by grimpirate » Thu Nov 01, 2012 7:22 am
After a lengthy IRC session through a couple of channels the fix was to create the following files with an [Install] section:

/usr/lib/systemd/system/raspi-restore.service
Code: Select all
[Unit]
Description=Restore RasPi time
DefaultDependencies=no
After=sysinit.target
Before=network.target
Conflicts=shutdown.target

[Service]
Type=oneshot
ExecStart=/home/tron/systemd/raspi-restore

[Install]
WantedBy=sysinit.target
/usr/lib/systemd/system/raspi-store.service
Code: Select all
[Unit]
Description=Store RasPi time
DefaultDependencies=no
Before=shutdown.target

[Service]
Type=oneshot
ExecStart=/home/tron/systemd/raspi-store

[Install]
WantedBy=shutdown.target
After issuing a systemctl daemon-reload and finally systemctl enable raspi-restore and systemctl enable raspi-store everything works as it should. Now the time used by the date binary is more recent, and at the very least updates while the RasPi is powered up.

The Before=network.target on the raspi-restore.service file should mean that the service is executed before the ntpd daemon (which updates the time via web). That should allow the system time to be updated correctly if a network connection is present. This is currently theory, as I've yet to see if when the RasPi is networked it does indeed return the correct time. I'll report back once I've tested it. For now, the RasPi's time is at least in the year 2012 as opposed to 1969.

The raspi-store, raspi-restore, and time.stamp files remain unchanged and in the /home/tron/systemd folder.
Posts: 38
Joined: Fri Oct 19, 2012 6:16 pm
by pepedog » Thu Nov 01, 2012 8:50 am
Very handy. fakeclock was used in the olden days of rc.d
Posts: 968
Joined: Fri Oct 07, 2011 9:55 am
by grimpirate » Thu Nov 01, 2012 5:38 pm
Thanks pepedog. I'm also happy to report that my assumption about the behavior was correct. I connected my Model B RasPi up to the network and powered it on, and it actualized the time using the ntpd service. When I powered it off, the last good time was saved to the time.stamp file. So now the RasPi's fake time will auto correct itself when possible.
Posts: 38
Joined: Fri Oct 19, 2012 6:16 pm
by blurpy » Sat Nov 03, 2012 7:15 pm
Hey,

I'm the author of KouChat, and I noticed your post. I have tried to fix the crash you experienced.
Could you give the current snapshot a test, to see if I got the fix right?

It's available from the build server,
at https://buildhive.cloudbees.com/job/blurpy/job/kouchat/lastStableBuild/net.usikkert.kouchat$kouchat/.
Posts: 4
Joined: Sat Nov 03, 2012 7:04 pm
by grimpirate » Sun Nov 04, 2012 6:45 am
I tested out the snapshot as per your instruction blurpy. To make sure it functioned, I reset the date on the RasPi using "date -s @0". I ran the 1.1.0 version to be sure the error was reproduced (it was). The 1.2.0 snapshot however did not produce the error, so it looks as though you've fixed it appropriately.

At the top of the stack trace it complained about a Timer.sched error, an IllegalArgumentException. Thanks for taking the time to look into it.
Posts: 38
Joined: Fri Oct 19, 2012 6:16 pm
by blurpy » Sun Nov 04, 2012 12:51 pm
No problem, and thanks for testing :)

The issue was that I tried to start a timer at the beginning of the day. And if the day was the first of January 1970, then depending on the time zone, the date would turn negative. Timers in Java don't accept negative dates (since the epoch).

So I solved it by starting the timer at the next hour (future), instead of at the beginning of the day (past). The next hour should not be negative, at least not in Linux. I was unable to set the date earlier than @0.
Posts: 4
Joined: Sat Nov 03, 2012 7:04 pm
by grimpirate » Mon Nov 05, 2012 3:53 am
Glad I could be of service blurpy. I would've posted the whole stack trace but the last thing I thought was that the author of KouChat would find his way here. Just goes to show you the internet gets smaller and smaller every day.
Posts: 38
Joined: Fri Oct 19, 2012 6:16 pm
by blurpy » Mon Nov 05, 2012 5:03 pm
Hehe, and the last thing I thought was that someone would run KouChat in "1970" :p
Very cool that it runs on a Raspberry Pi though!
Posts: 4
Joined: Sat Nov 03, 2012 7:04 pm
by grimpirate » Mon Nov 05, 2012 6:22 pm
Does indeed, runs pretty well too. It's a good thing you added console mode. If I may make a suggestion, do you think it would be possible to simplify the mechanism for file transfers in the console mode? I tried hitting "Tab" to complete the filename, but accepting a file requires you to type in the user that's sending the file as well as the filename itself (which can get pretty lengthy). I figure KouChat is probably intended to run in graphical mode, but given the RasPi's limited memory it helps make things a little faster in console.
Posts: 38
Joined: Fri Oct 19, 2012 6:16 pm
by blurpy » Tue Nov 06, 2012 6:54 am
Sounds like a good idea! I haven't had much focus on console mode as I didn't know anyone was using it. Could you create an issue with the feature request on the homepage of KouChat? I think we are getting a bit off topic here :)
Posts: 4
Joined: Sat Nov 03, 2012 7:04 pm
by pepedog » Mon Dec 17, 2012 9:41 pm
I forgot to comment, here is my take on fakeclock
http://myplugbox.com/fakeclock.tar.xz
It's not packaged, uses /var/log/everything.log to green a date.
Best to set date, and then restart syslog so current date is wrote, as long as end has current time
Posts: 968
Joined: Fri Oct 07, 2011 9:55 am
by sdjf » Wed Jan 09, 2013 2:36 am
I cannot unpack this on my Pi?

# unxz /boot/fakeclock.tar.xz
unxz: /boot/fakeclock.tar.xz: File format not recognized
# xz -d /boot/fakeclock.tar.xz
xz: /boot/fakeclock.tar.xz: File format not recognized
# md5sum /boot/fakeclock.tar.xz
62b669a1182795b7cbb69d928ad49e54 /boot/fakeclock.tar.xz
#

just downloaded another copy and md5sum is the same.

what am I doing wrong?
FORUM TIP: To view just one person's posting history, sign in, click on their user name, then click on "Search User's Posts." || This Pi owner is running Arch on 512MB Model B.
Posts: 1294
Joined: Fri Mar 16, 2012 5:20 am
Location: California
by grimpirate » Wed Jan 09, 2013 3:20 am
You don't unpack it, you install it using pacman -U
Posts: 38
Joined: Fri Oct 19, 2012 6:16 pm
by sdjf » Wed Jan 09, 2013 3:42 am
Pepedog clearly stated that it is not packaged. I get an error message when I use Pacman saying it is missing package metadata and also another error saying it is an invalid or corrupt package.
FORUM TIP: To view just one person's posting history, sign in, click on their user name, then click on "Search User's Posts." || This Pi owner is running Arch on 512MB Model B.
Posts: 1294
Joined: Fri Mar 16, 2012 5:20 am
Location: California
by pepedog » Wed Jan 09, 2013 9:07 am
Does this work?
tar xf fakeclock.tar.xz
Posts: 968
Joined: Fri Oct 07, 2011 9:55 am
by drirr » Wed Jan 09, 2013 4:46 pm
sdjf wrote:I cannot unpack this on my Pi?

# unxz /boot/fakeclock.tar.xz
unxz: /boot/fakeclock.tar.xz: File format not recognized
# xz -d /boot/fakeclock.tar.xz
xz: /boot/fakeclock.tar.xz: File format not recognized
# md5sum /boot/fakeclock.tar.xz
62b669a1182795b7cbb69d928ad49e54 /boot/fakeclock.tar.xz
#

just downloaded another copy and md5sum is the same.

what am I doing wrong?

Did you just grab it from the post above yours? If so it seems to be a badly named bzip2 tarball:
Code: Select all
$ file fakeclock.tar.xz
fakeclock.tar.bz2: bzip2 compressed data, block size = 900k

So either (force bzip2 extraction):
Code: Select all
$ tar xjf fakeclock.tar.xz
or (rename to bzip2 and let tar auto-magically decide the algorithm to use):
Code: Select all
$ mv fakeclock.tar.xz fakeclock.tar.bz2 && tar xf fakeclock.tar.bz2
Raspberry Pi (rev 000f, 512MB RAM) with heatsinks and a modmypi case running Arch Linux ARM (armv6h) hooked up to a 750GB 2.5" USB-harddrive
Posts: 54
Joined: Sun Sep 09, 2012 8:06 am
by sdjf » Wed Jan 09, 2013 5:43 pm
@drirr: thank you, I thought it was some other sort of archive, did not know about the file command.

@pepedog: yes, the tar xf did work, but I have delayed posting reply as wanted to add some comments for others who might not be able to figure out, on their own, how to install it properly. Will have to do that later, though.

I also have tried it and it may need some tweaking in my case, where it sometimes takes more than one reboot before I can actually set a real date. I may need to have it look at some log besides the everything.log to fetch a date.
FORUM TIP: To view just one person's posting history, sign in, click on their user name, then click on "Search User's Posts." || This Pi owner is running Arch on 512MB Model B.
Posts: 1294
Joined: Fri Mar 16, 2012 5:20 am
Location: California
by pepedog » Wed Jan 09, 2013 9:04 pm
Yes, you have to set date manually and wait for something to cause a write to everything.log
Restarting syslog-ng will do that (systemctl restart syslog-ng)
Posts: 968
Joined: Fri Oct 07, 2011 9:55 am