Problem setting time by NTP before starting the service on x86 V9.2-2 Upd2

OpenVMS x86 Field Test questions, reports, and feedback.
Post Reply
User avatar

Topic author
martinv
Master
Posts: 111
Joined: Fri Jun 14, 2019 11:05 pm
Reputation: 0
Location: Goslar, Germany
Status: Offline
Contact:

Problem setting time by NTP before starting the service on x86 V9.2-2 Upd2

Post by martinv » Wed Jun 05, 2024 6:55 am

Hi!

Following a comment in another thread I implemented the suggested procedure

Code: Select all

X86VMS::SYSTEM> tcpip show version

  VSI TCP/IP Services for OpenVMS x86_64 Version V6.0
  on a VMware, Inc. VMware7,1 running OpenVMS V9.2-2

X86VMS::SYSTEM> type sys$startup:tcpip$ntp_systartup.com
$ SET NOON
$ @SYS$SYSDEVICE:[TOOLS]CHECK_LINK_STATE.COM EIB0 5
$ IF $STATUS
$ THEN
$   WRITE SYS$OUTPUT "-----  Set time via NTP  -----"
$   MCR TCPIP$NTP.EXE -"G" -q sflmv.vmnet.
$ ENDIF
But that results in

Code: Select all

%%%%%%%%%%%  OPCOM   5-JUN-2024 11:51:02.86  %%%%%%%%%%%
Message from user INTERnet on X86VMS
%TCPIP-I-FSIPADDRUP, IE1 192.168.62.2 primary active on node X86VMS, interface IE1

%TCPIP-S-STARTDONE, TCP/IP Kernel startup completed
%TCPIP-I-PROXYLOADED, loaded 0 NFS proxy records
%TCPIP-I-LOADSERV, loading TCPIP server proxy information
%TCPIP-I-SERVLOADED, auxiliary server loaded with 0 proxy records
-TCPIP-I-SERVSKIP, skipped 0 communication proxy records
-TCPIP-I-SERVTOTAL, total of 0 proxy records read
%TCPIP-S-STARTDONE, TCPIP$PROXY startup completed
%TCPIP-S-STARTDONE, TCPIP$DHCP_CLIENT startup completed
%%%%%%%%%%%  OPCOM   5-JUN-2024 11:51:12.20  %%%%%%%%%%%
Message from user INTERnet on X86VMS
INTERnet ACP Activate FTP Server

%%%%%%%%%%%  OPCOM   5-JUN-2024 11:51:12.20  %%%%%%%%%%%
Message from user INTERnet on X86VMS
INTERnet ACP NOLISTEN Process creation success: Service - FTP

%TCPIP-S-STARTDONE, TCPIP$FTP startup completed
%TCPIP-S-STARTDONE, TCPIP$FTP_CLIENT startup completed
EIB0 link UP:0
-----  Set time via NTP  -----
ntp.exe[1027]: ntpd 4.2.8p15@1.3728 Fri Sep 22 07:00:58 UTC 2020 (2): Starting
ntp.exe[1027]: Command line: x86vms$dka0:[sys0.syscommon.][sysexe]tcpip$ntp.exe -G -q sflmv.vmnet.
ntp.exe[1027]: ----------------------------------------------------
ntp.exe[1027]: ntp-4 is maintained by Network Time Foundation,
ntp.exe[1027]: Inc. (NTF), a non-profit 501(c)(3) public-benefit
ntp.exe[1027]: corporation.  Support and training for ntp-4 are
ntp.exe[1027]: available at https://www.nwtime.org/support
ntp.exe[1027]: ----------------------------------------------------
%%%%%%%%%%%  OPCOM   5-JUN-2024 11:51:16.88  %%%%%%%%%%%
Message from user INTERnet on X86VMS
%TCPIP-I-FSIPADDRUP, IE0 172.16.1.85 primary active on node X86VMS, interface IE0

ntp.exe[1027]: proto: precision = 9999.900 usec (-7)
ntp.exe[1027]: proto: fuzz beneath 0.243 usec
ntp.exe[1027]: basedate set to 2024-01-11
ntp.exe[1027]: gps base set to 2024-01-14 (week 2297)
ntp.exe[1027]: Listen and drop on 0 v4wildcard 0.0.0.0:123
ntp.exe[1027]: Listen normally on 1 IE0 172.16.1.85:123
ntp.exe[1027]: Listen normally on 2 IE1 192.168.62.2:123
ntp.exe[1027]: Listen normally on 3 LO0 127.0.0.1:123
ntp.exe[1027]: Listening on routing socket on fd #4 for interface updates
ntp.exe[1027]: 0.0.0.0 c012 02 freq_set ntpd 0.833 PPM
ntp.exe[1027]: 0.0.0.0 c016 06 restart
ntp.exe[1027]: worker_sleep: sem_timedwait: invalid argument
ntp.exe[1027]: worker_sleep: sem_timedwait: invalid argument
ntp.exe[1027]: worker_sleep: sem_timedwait: invalid argument
ntp.exe[1027]: worker_sleep: sem_timedwait: invalid argument
ntp.exe[1027]: worker_sleep: sem_timedwait: invalid argument
with the last message repeated indefinitely.
sflmv.vmnet. is 192.168.62.1 (on VMware's host only network).

Before that, I had the following in sys$startup:tcpip$systartup.com

Code: Select all

$ @sys$startup:tcpip$ntp_shutdown.com
$ MCR TCPIP$NTP.EXE -"G" -q sflmv.vmnet.
$ @sys$startup:tcpip$ntp_startup.com
which works, but is clumsy.

Any ideas about the "worker_sleep: sem_timedwait: invalid argument"?

TIA,
Martin
What's the new buzzword to make on-premises sound cool again? "Cloudless"!


mzaharee
Visitor
Posts: 1
Joined: Wed Jun 05, 2024 11:14 am
Reputation: 0
Status: Offline

Re: Problem setting time by NTP before starting the service on x86 V9.2-2 Upd2

Post by mzaharee » Thu Jun 06, 2024 4:12 pm

You have a connectivity or name resolution problem with your specified time server. If you fix those, the error message you are seeing, the result of an unrelated bug, should go away.

- M

User avatar

Topic author
martinv
Master
Posts: 111
Joined: Fri Jun 14, 2019 11:05 pm
Reputation: 0
Location: Goslar, Germany
Status: Offline
Contact:

Re: Problem setting time by NTP before starting the service on x86 V9.2-2 Upd2

Post by martinv » Thu Jun 13, 2024 7:13 am

Thanks @mzaharee, that was indeed the problem. As soon as I replaced sflmv.vmnet. with one of the NTP providers on the local network, it started to work. It seemed like a good idea, though, to synch the VMS x86 system with its host system. I think it could been done by configuring the W32Time Windows service to act like a NTP server.

cu
Martin

Added in 14 minutes 22 seconds:
FWIW, I set up W32Time as an NTP server following these instructions, and my original tcpip$ntp_systartup.com works now.
What's the new buzzword to make on-premises sound cool again? "Cloudless"!

Post Reply