Deep standby time? Startup EPG problem

[Joe_90]

I take it you mean the one from the if-up.d scripts?

I can only find one instance of the ntpdate-sync script. It's in /usr/bin/. Do you think there's another? Removing the backgrounding solves the issue for me completely. Those extra seconds of delay seem to prevent the collision between the two calls.

Do you know what is calling ntpdate-sync when it is logged in the debug log early after the start of enigma:

<    19.9117> 15:58:46.0095 [Console] command: /usr/bin/ntpdate-sync
<    19.9118> 15:58:46.0096 [eConsoleAppContainer] Starting /bin/sh
<    19.9123> 15:58:46.0100 [Console] pid = 2254

EDIT - in reference to the stepping and slewing - stepping happens first time (if called from if-up.d) and forced by the "-b" parameter. Slewing happens on subsequent runs, providing the time adjustment is less than 0.5 seconds, otherwise ntpdate steps the time. I've read the man pages and played with the various parameter settings.

[birdman]

I can only find one instance of the ntpdate-sync script. It's in /usr/bin/. Do you think there's another?

No.

But it occurs to me that adding code to ensure it's only running once at a time can be done quite simply within the ntpdate-sync script itself using standard commands.
I'll have a go this evening....

[Joe_90]

Thanks @birdman. Do you know what's calling ntpdate-sync from enigma as I asked in post #76?

[Huevos]

Thanks @birdman. Do you know what's calling ntpdate-sync from enigma as I asked in post #76?

Yes, I know what is calling ntp-sync. I fixed that already. Needs testing. But I think I will remove the cronjob.

[Huevos]

No.

But it occurs to me that adding code to ensure it's only running once at a time can be done quite simply within the ntpdate-sync script itself using standard commands.
I'll have a go this evening....

Don't bother with that.

[Joe_90]

Yes, I know what is calling ntp-sync. I fixed that already. Needs testing. But I think I will remove the cronjob.

Can you enlighten?

EDIT - ignore. Found it in StartEnigma.py

Can test if you wish.

[Huevos]

Can you enlighten?

EDIT - ignore. Found it in StartEnigma.py

Can test if you wish.

So ignoring the cronjob for the time being... try these.

• /usr/lib/enigma2/python/StartEnigma.py
• /usr/lib/enigma2/python/Screens/Time.py
• /usr/lib/enigma2/python/Components/NetworkTime.py

[Joe_90]

Thanks @Huevos. Will be about an hour or so before I can test.


EDIT - all seems ok so far. I presume Time.py is used on initial start (First Install Wizard)? So, should I force a run through that?

As regards the console command to run ntpdate-sync in StartEnigma.py - you removed that, so it's not appearing in the messages log. However, the if-up.d (or whatever) seems to have generated a couple of calls to ntpdate. See time 17:31:23/24. (17:29 is the fake time). Interestingly, the cron job kicked in also as it was just past the scheduled time for that. But all times were "adjusted" (slewed) not "stepped" other than the initial one.

May 11 17:29:22 ax61 cron.info crond[2113]: (CRON) INFO (Syslog will be used instead of sendmail.)
May 11 17:29:22 ax61 cron.info crond[2113]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 17% if used.)
May 11 17:29:22 ax61 kern.info kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
May 11 17:29:23 ax61 daemon.info avahi-daemon[2103]: Server startup complete. Host name is ax61.local. Local service cookie is 936921535.
May 11 17:29:23 ax61 daemon.info avahi-daemon[2103]: Service "FTP file server on ax61" (/services/ftp.service) successfully established.
May 11 17:29:24 ax61 daemon.info avahi-daemon[2103]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::2e0:4cff:fe0d:398e.
May 11 17:29:24 ax61 daemon.info avahi-daemon[2103]: New relevant interface wlan0.IPv6 for mDNS.
May 11 17:29:24 ax61 daemon.info avahi-daemon[2103]: Registering new address record for fe80::2e0:4cff:fe0d:398e on wlan0.*.
May 11 17:31:23 ax61 daemon.notice ntpdate[2046]: step time server 194.58.202.148 offset +113.065724 sec
May 11 17:31:24 ax61 daemon.err ntpdate[2119]: no server suitable for synchronization found
May 11 17:31:24 ax61 kern.warn kernel: UDF-fs: warning (device mmcblk0p1): udf_fill_super: No partition found (2)
May 11 17:31:24 ax61 kern.warn kernel: UDF-fs: warning (device mmcblk0p1): udf_fill_super: No partition found (2)
May 11 17:31:24 ax61 kern.info kernel: yaffs: dev is 187695105 name is "mmcblk0p1" rw
May 11 17:31:24 ax61 kern.info kernel: yaffs: passed flags ""
May 11 17:31:24 ax61 kern.debug kernel: yaffs: yaffs: Attempting MTD mount of 179.1,"mmcblk0p1"
May 11 17:31:24 ax61 kern.debug kernel: yaffs: yaffs: MTD device 1 either not valid or unavailable
May 11 17:31:25 ax61 kern.info kernel: yaffs: dev is 187695105 name is "mmcblk0p1" rw
May 11 17:31:25 ax61 kern.info kernel: yaffs: passed flags ""
May 11 17:31:25 ax61 kern.debug kernel: yaffs: yaffs: Attempting MTD mount of 179.1,"mmcblk0p1"
May 11 17:31:25 ax61 kern.debug kernel: yaffs: yaffs: MTD device 1 either not valid or unavailable
May 11 17:31:25 ax61 kern.info kernel: tntfs info (device mmcblk0p1, pid 2151): ntfs_fill_super(): fail_safe is enabled.
May 11 17:31:25 ax61 kern.warn kernel: UDF-fs: warning (device mmcblk0p3): udf_fill_super: No partition found (2)
May 11 17:31:25 ax61 kern.warn kernel: UDF-fs: warning (device mmcblk0p3): udf_fill_super: No partition found (2)
May 11 17:31:25 ax61 kern.info kernel: yaffs: dev is 187695107 name is "mmcblk0p3" rw
May 11 17:31:25 ax61 kern.info kernel: yaffs: passed flags ""
May 11 17:31:25 ax61 kern.debug kernel: yaffs: yaffs: Attempting MTD mount of 179.3,"mmcblk0p3"
May 11 17:31:25 ax61 kern.debug kernel: yaffs: yaffs: MTD device 3 either not valid or unavailable
May 11 17:31:25 ax61 kern.info kernel: yaffs: dev is 187695107 name is "mmcblk0p3" rw
May 11 17:31:25 ax61 kern.info kernel: yaffs: passed flags ""
May 11 17:31:25 ax61 kern.debug kernel: yaffs: yaffs: Attempting MTD mount of 179.3,"mmcblk0p3"
May 11 17:31:25 ax61 kern.debug kernel: yaffs: yaffs: MTD device 3 either not valid or unavailable
May 11 17:31:25 ax61 kern.info kernel: tntfs info (device mmcblk0p3, pid 2190): ntfs_fill_super(): fail_safe is enabled.
May 11 17:31:33 ax61 daemon.info automount[2071]: key "logs" not found in map source(s).
May 11 17:31:54 ax61 authpriv.info crond[2256]: pam_unix(crond:session): session opened for user root(uid=0) by (uid=0)
May 11 17:31:54 ax61 cron.info CROND[2257]: (root) CMD (/usr/bin/ntpdate-sync silent)
May 11 17:32:01 ax61 daemon.notice ntpdate[2261]: adjust time server 85.91.1.164 offset +0.007328 sec
May 11 17:32:01 ax61 cron.info CROND[2256]: (root) CMDEND (/usr/bin/ntpdate-sync silent)
May 11 17:32:01 ax61 authpriv.info CROND[2256]: pam_unix(crond:session): session closed for user root

[birdman]

Don't bother with that.

Done it already.

This is a better ntpdate-sync script. Just exits if another is already running.

EDIT: replaced with a better(?) version in https://www.world-of-satellite.com/s...l=1#post525318

[Joe_90]

Done it already.

This is a better ntpdate-sync script. Just exits if another is already running.

Attachment 63872

I'll leave that for a while until my previous debug/messages files are looked at.

But, I notice that you removed the backgrounding from line 52 in the original file and moved it to the actual ntpdate call. The original also has a commented out line 63 (an ampersand). So, in your new script all the lockfile creation and check is in the foreground, correct? Maybe the original script was somewhat buggy to begin with

[Huevos]

Lock file = not a good idea.

[birdman]

So, in your new script all the lockfile creation and check is in the foreground, correct?

Yes. the comments imply that the backgrounding is done because of how ntpdate/ntpd run in systemd systems.
The locking (or whatever you call what is now there) has got nothing to do with this, so there's no reason to background it.

[Joe_90]

Yes. the comments imply that the backgrounding is done because of how ntpdate/ntpd run in systemd systems.
The locking (or whatever you call what is now there) has got nothing to do with this, so there's no reason to background it.

But doesn't vix use init, rather than systemd? Just asking.

[birdman]

But doesn't vix use init, rather than systemd? Just asking.

Yes. But the script might be used elsewhere. Since I didn't need to break the logic, I didn't.