systemd & date for manual setting of clock

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?

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.

Very handy. fakeclock was used in the olden days of rc.d

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.

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/.

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.

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.

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.

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!

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.

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

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

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?

You don't unpack it, you install it using pacman -U

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.

Does this work?
tar xf fakeclock.tar.xz

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

@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.

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)