How to start Transmission after clock is adjusted by NTP?

[vrapp]

If I install Transmission as documented at https://github.com/RMerl/asuswrt-merlin/wiki/Installing-Transmission-through-Entware , it looks like after router restart, Transmission starts before the clock gets adjusted by NTP, which results in Transmission running in GMT zone. Is there a way to configure startup scripts so that Transmission starts after NTP has adjusted the clock?

(I already posted about this problem here, but solution was not found; thanks to x190 at https://forum.transmissionbt.com/viewtopic.php?f=8&t=17283&p=71722#p71722 for the idea)

 

[TeHashX]

If I install Transmission as documented at https://github.com/RMerl/asuswrt-merlin/wiki/Installing-Transmission-through-Entware , it looks like after router restart, Transmission starts before the clock gets adjusted by NTP, which results in Transmission running in GMT zone. Is there a way to configure startup scripts so that Transmission starts after NTP has adjusted the clock?

(I already posted about this problem here, but solution was not found; thanks to x190 at https://forum.transmissionbt.com/viewtopic.php?f=8&t=17283&p=71722#p71722 for the idea)

Add to /jffs/scripts/post-mount

sleep 30
/opt/etc/init.d/S88transmission restart

 

[Calisro]

I would personally do it differently. I would have your startup actually wait for the ntp sync in case the WAN is down or something.

I would disable auto-starting of transmission out of /opt/etc/init.d

cd /opt/etc/init.d/
mv S88transmission D88transmission

Then I would create a script like this to start it appropriately:
/jffs/scripts/transmissionstart.sh

#!/bin/sh
YR=`date +"%Y"`
[[ "$YR" -ge "2015" ]] && /opt/etc/init.d/D88transmission start

CRUNAME=transmission-daemon
cru l | grep $CRUNAME >/dev/null || cru a $CRUNAME "*/5 * * * * $0 $*"
exit 0

Make it executable

chmod +x  /jffs/scripts/transmissionstart.sh

Lastly, add this line into /jffs/scripts/post-mount

/jffs/scripts/transmissionstart.sh

This will run that script on start. It will check to see if the year is 2015 or greater (indicating ntp ran) and then start the service. If the year is not greater than 2015 (indicating that ntp has not run yet, it won't start it.

It will also add a cru job (if one does not exist) to run every 5 minutes to make sure you're transmission daemon is running so that if it dies, it will re-start it.

 

[joegreat]

I would personally do it differently. I would have your startup actually wait for the ntp sync in case the WAN is down or something.

Hi,

Are you sure that your approach works?
I restarted Transmission after time was set correctly and it runs still 2h behind CET timezone (on GMT without DST)...

To me it looks more like Transmission is not respecting the timezone as the time is correct, just it's 2h behind due to the wrong timezone.

With kind regards
Joe

 

[Calisro]

Hi,

Are you sure that your approach works?
I restarted Transmission after time was set correctly and it runs still 2h behind CET timezone (on GMT without DST)...

To me it looks more like Transmission is not respecting the timezone as the time is correct, just it's 2h behind due to the wrong timezone.

With kind regards
Joe

I was solving the ask of "Is there a way to configure startup scripts so that Transmission startsafter NTP has adjusted the clock". I am not sure if this will fix transmission but it will start transmission after the time is set with NTP.

 

[Calisro]

i was reading config info for optware. In the transmission conf file, try adfing this. Just a shot in the dark.

TIMEZONE_OFFSET=+3600

obviously adjust for your tz.

ref:
http://www.nslu2-linux.org/wiki/Optware/Transmission

 

[joegreat]

i was reading config info for optware. In the transmission conf file, try adfing this. Just a shot in the dark.

TIMEZONE_OFFSET=+3600

obviously adjust for your tz.

ref:
http://www.nslu2-linux.org/wiki/Optware/Transmission

Hi,

No success!

The Transmission version on Entware is using the settings.json configuration file located in /opt/etc/transmission/ - which does not support the setting of time offset or timezone.

The referenced other config file is just not used on Entware - it's only for "for transmission on NSLU2 with Unslung 6.8" - as the headline says.

ref: https://trac.transmissionbt.com/wiki/EditConfigFiles

With kind regards
Joe

 

[kvic]

I'm okay with wrong timezone in the log... But the issue can be fixed with this:

#!/bin/sh

ENABLED=yes
PROCS=transmission-daemon
ARGS="-g /opt/etc/transmission"
PRECMD="TZ=GMT-8"
PREARGS=""
DESC=$PROCS
PATH=/opt/sbin:/opt/bin:/opt/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

. /opt/etc/init.d/rc.func

Insert the line PRECMD, and replace GMT-8 with your timezone.
The same trick can fix wrong time in other Entware apps if they're...on a per app basis.

p.s. It's not Entware apps fault nor NTP actually.

 

[joegreat]

p.s. It's not Entware apps fault nor NTP actually.

Hi,

Success!
The TZ variable with the GMT-xx setting works fine for me!

Only one question remains: What happens after DST (daylight saving time) is over?
Then one hour less need to be set, right? Any idea to automate this topic?

With kind regards
Joe

 

[kvic]

Hi,

Success!
The TZ variable with the GMT-xx setting works fine for me!

Only one question remains: What happens after DST (daylight saving time) is over?
Then one hour less need to be set, right? Any idea to automate this topic?

With kind regards
Joe

Good question. lol. But don't bother. Work on something more fun

 

[Calisro]

I'm okay with wrong timezone in the log... But the issue can be fixed with this:

#!/bin/sh

ENABLED=yes
PROCS=transmission-daemon
ARGS="-g /opt/etc/transmission"
PRECMD="TZ=GMT-8"
PREARGS=""
DESC=$PROCS
PATH=/opt/sbin:/opt/bin:/opt/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

. /opt/etc/init.d/rc.func

Insert the line PRECMD, and replace GMT-8 with your timezone.
The same trick can fix wrong time in other Entware apps if they're...on a per app basis.

p.s. It's not Entware apps fault nor NTP actually.

nice. Since its using a standard TZ variable, I wonder if it would accept just a time zone.

PRECMD="TZ=America/New_York"

 

[kvic]

nice. Since its using a standard TZ variable, I wonder if it would accept just a time zone.

PRECMD="TZ=America/New_York"

According to this doc, probably won't work. Worth a try..

@joegreat DST seems doable ... the second format in the doc

 

[joegreat]

According to this doc, probably won't work. Worth a try..

@joegreat DST seems doable ... the second format in the doc

Hi,

OK. Now I use for TZ the following format for central Europe region: TZ="GMT-2,M3.4.0/-2,M10.4.0/-1"
Works correctly, but we need to wait until October to see if the DST switching works as well.

Thank's a lot for taking the time to find the solution!

With kind regards
Joe

PS.: And now I can do something different...

 

[vrapp]

In my case, Transmission 2.84 works in correct timezone (writing correct timestamp in log records, and alternative speed schedule works with the local time) without any further effort, as long as it's started after ntp has set the clock. Maybe it's because I had file /etc/TZ with this content:

CST6DST,M3.2.0/2,M10.2.0/2

 

[kvic]

@vrapp Interesting... but unlikely your observations are correct. Could you restart transmission from command line and post snippets of syslog like @joegreat did in your original thread?

 

[vrapp]

Aug 21 06:42:40 dropbear[22639]: Child connection from 192.168.1.2:61114
Aug 21 06:42:47 dropbear[22639]: Password auth succeeded for 'admin' from 192.168.1.2:61114
Aug 21 06:43:44 transmission-daemon[21318]: Closing session
Aug 21 06:43:48 admin: Started transmission-daemon from .
Aug 21 06:43:59 transmission-daemon[22674]: UDP Failed to set receive buffer: requested 4194304, got 237568 (tr-udp.c:78)
Aug 21 06:43:59 transmission-daemon[22674]: UDP Failed to set send buffer: requested 1048576, got 237568 (tr-udp.c:89)

 

[kvic]

Aug 21 06:42:40 dropbear[22639]: Child connection from 192.168.1.2:61114
Aug 21 06:42:47 dropbear[22639]: Password auth succeeded for 'admin' from 192.168.1.2:61114
Aug 21 06:43:44 transmission-daemon[21318]: Closing session
Aug 21 06:43:48 admin: Started transmission-daemon from .
Aug 21 06:43:59 transmission-daemon[22674]: UDP Failed to set receive buffer: requested 4194304, got 237568 (tr-udp.c:78)
Aug 21 06:43:59 transmission-daemon[22674]: UDP Failed to set send buffer: requested 1048576, got 237568 (tr-udp.c:89)

U may go ahead with @Calisro's suggestion that shall solve ur problem.

 

[ryzhov_al]

opkg install fake-hwclock

 

[ryzhov_al]

As for me, I put fake-hwclock right into JFFS partition, it's just a shell script. Check this out, router got actual time at 7 second of boot. \w/

 

[kvic]

@ryzhov_al nice one.

EDIT:

Got the following from my most recent boot:

Jan  1 08:00:35 ntp: start NTP update
Aug 19 15:59:35 openvpn-routing: Refreshing policy rules for client 1
...
Aug 19 15:59:56 syslogd exiting
Aug 19 15:59:56 phaeo syslog-ng[1158]: syslog-ng starting up; version='2.1.4'

System clock updates at 35s after boot. First Entware job syslog-ng starts at 56s after boot (or 21s after clock updated). Transmission is towards the very end of my Entware job list.