I'm moving ancient code from an existing test infrastructure to ADO. Some of this code relies on the fact that it's never been run outside of PST (questionable date math). Is there some way to configure or reset the timezone in a windows hosted agent in devops? I tried just executing tzutil, but it wasn't found.
You can run the following sample bash script using Microsoft hosted agent to configure the timezone.
echo "checking date"
date
echo "setting date to Asia/Kolkata"
sudo timedatectl set-timezone "Asia/Kolkata"
date
The results in the log:
2019-07-05T20:26:48.5992486Z checking date
2019-07-05T20:26:48.5992954Z Fri Jul 5 20:26:48 UTC 2019
2019-07-05T20:26:48.5993264Z setting date to Asia/Kolkata
2019-07-05T20:26:48.9107025Z Sat Jul 6 01:56:48 IST 2019
You can refer to this ticket for details.
Related
We have a linux system that we are building with yocto.
We can read our hardware clock after reboots, change both system time and hardware time without any error (most of the time). However; after some new month, every year that we have tried we are running in to this error. "hwclock: RTC_RD_TIME: Invalid argument".
Example 1:
root#:~# date
Thu Apr 30 23:59:50 UTC 2020
root#:~# hwclock
Thu Apr 30 23:59:52 2020 0.000000 seconds
root#:~#
root#:~#
root#:~# date
Fri May 1 00:00:10 UTC 2020
root#:~# hwclock
hwclock: RTC_TD_TIME: Invalid argument
root#:~#
This is not happening every new month, if I do the same test in January linux can read the hwclock without any issues. It does also not matter if the unit is powered or not. If I set the hwclock to first of May 00:00:00 it can keep track of the time.
The same error occurs on the following month shift:
Feb (it does not matter if it is leap year or not) -> Mar
Apr -> May
Jun -> Jul
Sep -> Oct
Nov -> Dec
Dec (Not sure because of new year or new month) -> Jan
In my understanding, this is happening because rtc-lib.c cannot verify the time correctly.
I have tried on multiple different hardware
Does anyone have any idea what might cause this?
Solution:
The fault was not in rtc-lib.c. The cause of the error was a faulty RTC implementation. The RTC month value is 1-indexed, but the kernel assumes it is 0-indexed. Added a patch for this to rtc-[my_rtc_model].c and now it seems to be working.
I have a scheduled task that executes a sqlplus command, with username and password supplied.
Intermittently there is a ORA-12170: TNS:Connect timeout occurred that occurs. After these happen, SQL*Plus asks for a username, which never times out, pausing my task indefinitely.
How can I guard against this? Is there any command line option that can prevent this?
Task batch file
...
sqlplus user/\"password\"#database#script.sql >> "script.log"
script.sql
START TRANSACTION;
call schema.sync_task();
COMMIT;
quit;
successful log
SQL*Plus: Release 12.1.0.2.0 Production on Mon Sep 10 22:15:00 2018
Copyright (c) 1982, 2014, Oracle. All rights reserved.
Last Successful login time: Mon Sep 10 2018 22:10:00 -04:00
Connected to:
Oracle Database 12c Standard Edition Release 12.1.0.2.0 - 64bit Production
With the Automatic Storage Management option
SP2-0310: unable to open file "TRANSACTION.sql"
Call completed.
Commit complete.
Disconnected from Oracle Database 12c Standard Edition Release 12.1.0.2.0 - 64bit Production
With the Automatic Storage Management option
failed log
SQL*Plus: Release 12.1.0.2.0 Production on Mon Sep 10 22:20:00 2018
Copyright (c) 1982, 2014, Oracle. All rights reserved.
ERROR:
ORA-12170: TNS:Connect timeout occurred
Enter user-name:
I didn't find a clean solution, but I did find the simple one.
I've modified the settings of the scheduled task to stop if running longer than an hour. 10 minutes would have been better, but that wasn't an option in the task scheduler.
I've been trying to set up the correct date in my Beaglebone Black but the solutions I've tried are not permanent, everytime I poweroff the Beagle and power on later, the date is wrong again.
So this is what initially looks like:
root#beaglebone:~# date
Sat May 21 17:48:28 CDT 2016
Then I installed ntp and ntpdate
root#beaglebone:~# apt-get install ntp ntpdate
Reading package lists... Done
Building dependency tree
Reading state information... Done
ntp is already the newest version.
ntpdate is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
After that I edit the ntp.conf file like this
# pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will
# pick a different set every time it starts up. Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 0.north-america.pool.ntp.org
server 1.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org
server 3.north-america.pool.ntp.org
...
# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust
restrict 192.168.0.11 mask 255.255.255.0 nomodify notrap
The next step was
root#beaglebone:~# rm /etc/localtime
root#beaglebone:~# ln -s /usr/share/zoneinfo/America/Mexico_City /etc/localtime
After that I was supposed to enable the ntp service with
root#beaglebone:~# systemctl enable ntpdate.service
Failed to enable unit: No such file or directory
or
root#beaglebone:~# service ntpdate start
Failed to start ntpdate.service: Unit ntpdate.service not found.
I couldn't continue with thas because I don't have the ntp.service file so then I tried this
root#beaglebone:~# timedatectl set-ntp true
root#beaglebone:~# timedatectl status
Local time: Sat 2016-05-21 18:16:10 CDT
Universal time: Sat 2016-05-21 23:16:10 UTC
RTC time: Sat 2016-05-21 23:16:11
Time zone: America/Mexico_City (CDT, -0500)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
root#beaglebone:~# nano /etc/systemd/timesyncd.conf
[Time]
NTP=0.north-america.pool.ntp.org 1.north-america.pool.ntp.org 2.north-america.pool.ntp.org 3.north-america.pool.ntp.org
FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
Finally I reboot and seems to work
root#beaglebone:~# timedatectl status
Local time: Sun 2017-09-10 23:32:28 CDT
Universal time: Mon 2017-09-11 04:32:28 UTC
RTC time: Mon 2017-09-11 04:32:28
Time zone: America/Mexico_City (CDT, -0500)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
But then again, after poweroff the time sets itself back to May 21st, 2016. I even tried set and sync the clock manually with hwclock --set --date "date" --localtime and systohc but after poweroff the result is the same.
Am I missing something or doing something wrong?
I also change 'UTC' to 'LOCAL' in /etc/adjtime and time goes back to May 2016.
Thanks.
Try this:
dpkg-reconfigure tzdata
This should work. A prompt appears and you can configure it with a graphical interface. It is as easy as America and enter. And then, you can pick your time zone, too.
Seth
I'm trying to apply the timezone Europe/Berlin on a Raspberry PI running the Debian-based Raspbian.
sudo dpkg-reconfigure tzdata
returns
Current default time zone: 'Europe/Berlin'
Local time is now: Sun Jun 25 20:26:51 CEST 2017.
Universal Time is now: Sun Jun 25 18:26:51 UTC 2017.
but
sudo date
still returns the British Summer Time (BST) instead of the Europe/Berlin Central European Summer Time (CEST)
Sun Jun 25 19:26:55 BST 2017
If there is internet connection available follow the steps to set the
date/time:
sudo raspi-config
Internationalization options
Change Time Zone
Select geographical area
Select city or region.
Reboot your pi.
This way, you will have accurate time. Need not set the date again for every boot.
I need to use the CLI to see the time in arbitrary timezones. However, Debian doesn't respond to the recommended solution.
First, I set the local timezone.
dpkg-reconfigure tzdata
Then, I set the system time.
ntpdate pool.ntp.org
I update the hardware clock to reflect the system time.
hwclock --systohc --utc
Now, I follow this post:
http://www.linuxquestions.org/questions/programming-9/display-different-timezones-in-command-line-927660/
Which says that I can complete my task using a command such as this:
TZ=UTC date && TZ=CDT date && TZ=IST date
However, this is the output I get:
dpkg-reconfigure tzdata && ntpdate pool.ntp.org && hwclock --systohc --utc && TZ=UTC date && TZ=CDT date && TZ=IST date
Current default time zone: 'America/Chicago'
Local time is now: Tue Apr 16 14:45:29 CDT 2013.
Universal Time is now: Tue Apr 16 19:45:29 UTC 2013.
16 Apr 19:45:38 ntpdate[12036]: adjust time server 199.102.46.73 offset -0.036668 sec
Tue Apr 16 19:45:39 UTC 2013
Tue Apr 16 19:45:39 CDT 2013
Tue Apr 16 19:45:39 IST 2013
CDT and IST aren't valid timezone names, so date is defaulting to show you UTC time if you attempt to use those as your timezone.
I'm not sure which timezones you actually meant to use, but try a couple of these. They are valid timezone names.
TZ=Asia/Shanghai date
TZ=America/Vancouver date
TZ=Europe/London date