Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #268082 > unrolled thread

Re: strange time problem with bullseye

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: strange time problem with bullseye Teemu Likonen <tlikonen@iki.fi> - 2024-03-06 06:40 +0100
    Re: strange time problem with bullseye Greg Wooledge <greg@wooledge.org> - 2024-03-06 13:10 +0100
      Re: strange time problem with bullseye Jeffrey Walton <noloader@gmail.com> - 2024-03-06 19:10 +0100
      Re: strange time problem with bullseye David Wright <deblis@lionunicorn.co.uk> - 2024-03-06 20:30 +0100
    Re: strange time problem with bullseye "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-03-06 18:20 +0100
      Re: strange time problem with bullseye Teemu Likonen <tlikonen@iki.fi> - 2024-03-06 18:40 +0100
        Re: strange time problem with bullseye Greg Wooledge <greg@wooledge.org> - 2024-03-06 18:50 +0100
          Re: strange time problem with bullseye gene heskett <gheskett@shentel.net> - 2024-03-07 00:00 +0100
            Re: strange time problem with bullseye Greg Wooledge <greg@wooledge.org> - 2024-03-07 00:10 +0100
              Re: strange time problem with bullseye gene heskett <gheskett@shentel.net> - 2024-03-07 02:40 +0100
                Re: strange time problem with bullseye John Hasler <john@sugarbit.com> - 2024-03-07 03:10 +0100
                  Re: strange time problem with bullseye <tomas@tuxteam.de> - 2024-03-07 06:30 +0100
                    Re: strange time problem with bullseye gene heskett <gheskett@shentel.net> - 2024-03-07 14:40 +0100
                      Re: strange time problem with bullseye <tomas@tuxteam.de> - 2024-03-07 14:50 +0100
                        Re: strange time problem with bullseye Jeffrey Walton <noloader@gmail.com> - 2024-03-07 17:20 +0100
                          Re: strange time problem with bullseye gene heskett <gheskett@shentel.net> - 2024-03-07 17:40 +0100
                      Re: strange time problem with bullseye Teemu Likonen <tlikonen@iki.fi> - 2024-03-07 15:10 +0100
                        Re: strange time problem with bullseye "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-03-07 20:40 +0100
                          Re: strange time problem with bullseye Greg Wooledge <greg@wooledge.org> - 2024-03-07 20:50 +0100
                            Re: strange time problem with bullseye "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-03-08 18:30 +0100
                      Re: strange time problem with bullseye Greg Wooledge <greg@wooledge.org> - 2024-03-07 17:00 +0100
                        Re: strange time problem with bullseye gene heskett <gheskett@shentel.net> - 2024-03-07 17:40 +0100
                          Re: strange time problem with bullseye/buster David Wright <deblis@lionunicorn.co.uk> - 2024-03-07 18:20 +0100
                            Re: strange time problem with bullseye/buster gene heskett <gheskett@shentel.net> - 2024-03-08 01:20 +0100
                              Re: strange time problem with bullseye/buster David Wright <deblis@lionunicorn.co.uk> - 2024-03-08 03:40 +0100
                                Re: strange time problem with bullseye/buster gene heskett <gheskett@shentel.net> - 2024-03-08 04:30 +0100
                              Re: strange time problem with bullseye/buster Max Nikulin <manikulin@gmail.com> - 2024-03-08 17:20 +0100
                Re: strange time problem with bullseye Greg Wooledge <greg@wooledge.org> - 2024-03-07 03:40 +0100
                  Re: strange time problem with bullseye <tomas@tuxteam.de> - 2024-03-07 06:30 +0100
          Re: strange time problem with bullseye "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-03-07 20:20 +0100
            Re: strange time problem with bullseye Dan Ritter <dsr@randomstring.org> - 2024-03-07 20:50 +0100
            Re: strange time problem with bullseye gene heskett <gheskett@shentel.net> - 2024-03-08 01:30 +0100
      Re: strange time problem with bullseye Jeffrey Walton <noloader@gmail.com> - 2024-03-06 18:50 +0100

Page 1 of 2  [1] 2  Next page →

#268082 — Re: strange time problem with bullseye

[Multipart message — attachments visible in raw view] — view raw

* 2024-03-06 02:47:06+0800, hlyg wrote:

> my newly-installed deb11 for amd64 shows wrong time,  it lags behind
> correct time by 8 hours though difference between universal and local
> is ok.

It seems that you have solved the problem but here is another hint.
"timedatectl" is a good high-level tool for querying and adjusting time
settings. Without command-line arguments it prints a lot of useful info:

    $ timedatectl
                   Local time: ke 2024-03-06 07:33:00 EET
               Universal time: ke 2024-03-06 05:33:00 UTC
                     RTC time: ke 2024-03-06 05:33:00
                    Time zone: Europe/Helsinki (EET, +0200)
    System clock synchronized: yes
                  NTP service: active
              RTC in local TZ: no

See "timedatectl -h" or manual page for more info.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462

[toc] | [next] | [standalone]

#268092

On Wed, Mar 06, 2024 at 07:37:09AM +0200, Teemu Likonen wrote:
> It seems that you have solved the problem but here is another hint.
> "timedatectl" is a good high-level tool for querying and adjusting time
> settings. Without command-line arguments it prints a lot of useful info:
> 
>     $ timedatectl
>                    Local time: ke 2024-03-06 07:33:00 EET
>                Universal time: ke 2024-03-06 05:33:00 UTC
>                      RTC time: ke 2024-03-06 05:33:00
>                     Time zone: Europe/Helsinki (EET, +0200)
>     System clock synchronized: yes
>                   NTP service: active
>               RTC in local TZ: no
> 
> See "timedatectl -h" or manual page for more info.

This is a great hint, but be warned that it doesn't quite know about
NTP services other than systemd-timesyncd.  If you're running ntpsec,
for example, it'll simply say:

System clock synchronized: yes
              NTP service: n/a

[toc] | [prev] | [next] | [standalone]

#268112

On Wed, Mar 6, 2024 at 7:08 AM Greg Wooledge <greg@wooledge.org> wrote:
>
> On Wed, Mar 06, 2024 at 07:37:09AM +0200, Teemu Likonen wrote:
> > It seems that you have solved the problem but here is another hint.
> > "timedatectl" is a good high-level tool for querying and adjusting time
> > settings. Without command-line arguments it prints a lot of useful info:
> >
> >     $ timedatectl
> >                    Local time: ke 2024-03-06 07:33:00 EET
> >                Universal time: ke 2024-03-06 05:33:00 UTC
> >                      RTC time: ke 2024-03-06 05:33:00
> >                     Time zone: Europe/Helsinki (EET, +0200)
> >     System clock synchronized: yes
> >                   NTP service: active
> >               RTC in local TZ: no
> >
> > See "timedatectl -h" or manual page for more info.
>
> This is a great hint, but be warned that it doesn't quite know about
> NTP services other than systemd-timesyncd.  If you're running ntpsec,
> for example, it'll simply say:
>
> System clock synchronized: yes
>               NTP service: n/a

This may help in the future:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065567>.

Jeff

[toc] | [prev] | [next] | [standalone]

#268115

On Wed 06 Mar 2024 at 07:07:36 (-0500), Greg Wooledge wrote:
> On Wed, Mar 06, 2024 at 07:37:09AM +0200, Teemu Likonen wrote:
> > It seems that you have solved the problem but here is another hint.
> > "timedatectl" is a good high-level tool for querying and adjusting time
> > settings. Without command-line arguments it prints a lot of useful info:
> > 
> >     $ timedatectl
> >                    Local time: ke 2024-03-06 07:33:00 EET
> >                Universal time: ke 2024-03-06 05:33:00 UTC
> >                      RTC time: ke 2024-03-06 05:33:00
> >                     Time zone: Europe/Helsinki (EET, +0200)
> >     System clock synchronized: yes
> >                   NTP service: active
> >               RTC in local TZ: no
> > 
> > See "timedatectl -h" or manual page for more info.
> 
> This is a great hint, but be warned that it doesn't quite know about
> NTP services other than systemd-timesyncd.  If you're running ntpsec,
> for example, it'll simply say:
> 
> System clock synchronized: yes
>               NTP service: n/a

Note also that it only shows the system's time zone, and not
necessarily that of the user running it:

$ timedatectl ; echo ; date
               Local time: Wed 2024-03-06 19:18:58 UTC
           Universal time: Wed 2024-03-06 19:18:58 UTC
                 RTC time: Wed 2024-03-06 19:18:58
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Wed Mar  6 13:18:58 CST 2024
$ 

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#268105

On Wednesday 06 March 2024 12:37:09 am Teemu Likonen wrote:
> * 2024-03-06 02:47:06+0800, hlyg wrote:
> 
> > my newly-installed deb11 for amd64 shows wrong time,  it lags behind
> > correct time by 8 hours though difference between universal and local
> > is ok.
> 
> It seems that you have solved the problem but here is another hint.
> "timedatectl" is a good high-level tool for querying and adjusting time
> settings. Without command-line arguments it prints a lot of useful info:
> 
>     $ timedatectl
>                    Local time: ke 2024-03-06 07:33:00 EET
>                Universal time: ke 2024-03-06 05:33:00 UTC
>                      RTC time: ke 2024-03-06 05:33:00
>                     Time zone: Europe/Helsinki (EET, +0200)
>     System clock synchronized: yes
>                   NTP service: active
>               RTC in local TZ: no
> 
> See "timedatectl -h" or manual page for more info.
> 

Mine shows:

      Local time: Wed 2024-03-06 12:09:44 EST
  Universal time: Wed 2024-03-06 17:09:44 UTC
        RTC time: Wed 2024-03-06 17:20:53
       Time zone: America/New_York (EST, -0500)
 Network time on: yes
NTP synchronized: no
 RTC in local TZ: no

How do I get the RTC to agree with the right time?  I don't reboot this often,  but when I do the time displayed on the onscreen clock is typically off by several minutes.

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

[toc] | [prev] | [next] | [standalone]

#268107

[Multipart message — attachments visible in raw view] — view raw

* 2024-03-06 12:31:46-0500, Roy J. Tellason, Sr. wrote:

>       Local time: Wed 2024-03-06 12:09:44 EST
>   Universal time: Wed 2024-03-06 17:09:44 UTC
>         RTC time: Wed 2024-03-06 17:20:53
>        Time zone: America/New_York (EST, -0500)
>  Network time on: yes
> NTP synchronized: no
>  RTC in local TZ: no
>
> How do I get the RTC to agree with the right time? I don't reboot this
> often, but when I do the time displayed on the onscreen clock is
> typically off by several minutes.

RTC is the clock on computer's motherboard. It has battery and it can
keep time when the computer is off. That's its purpose. When computer is
shut down the operating system saves its time to RTC. When computer is
booted operating system reads RTC time and sets operating system's
clock. The time is not accurate but at very least it's something instead
of random time. When operating system is running RTC does not matter
anymore.

To get operating system's clock have accurate time it needs to be
synchronized with network time servers via network time protocol (NTP).
Systemd has that feature. Turn in on with

    sudo timedatectl set-ntp true

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462

[toc] | [prev] | [next] | [standalone]

#268109

On Wed, Mar 06, 2024 at 12:31:46PM -0500, Roy J. Tellason, Sr. wrote:
> Mine shows:
> 
>       Local time: Wed 2024-03-06 12:09:44 EST
>   Universal time: Wed 2024-03-06 17:09:44 UTC
>         RTC time: Wed 2024-03-06 17:20:53
>        Time zone: America/New_York (EST, -0500)
>  Network time on: yes
> NTP synchronized: no
>  RTC in local TZ: no
> 
> How do I get the RTC to agree with the right time?

"hwclock -w" to copy the system clock to the hardware clock (RTC).  This
should also be done during shutdown, but it doesn't hurt to do it now.


On Wed, Mar 06, 2024 at 07:36:11PM +0200, Teemu Likonen wrote:
> To get operating system's clock have accurate time it needs to be
> synchronized with network time servers via network time protocol (NTP).
> Systemd has that feature. Turn in on with
> 
>     sudo timedatectl set-ntp true

But *don't* do that if you're using some other NTP program instead of
systemd-timesyncd.  Unfortunately, timedatectl does not know about other
NTP programs, and won't report which one you're using.  You'll have
to find that out yourself.

[toc] | [prev] | [next] | [standalone]

#268119

On 3/6/24 12:42, Greg Wooledge wrote:
> On Wed, Mar 06, 2024 at 12:31:46PM -0500, Roy J. Tellason, Sr. wrote:
>> Mine shows:
>>
>>        Local time: Wed 2024-03-06 12:09:44 EST
>>    Universal time: Wed 2024-03-06 17:09:44 UTC
>>          RTC time: Wed 2024-03-06 17:20:53
>>         Time zone: America/New_York (EST, -0500)
>>   Network time on: yes
>> NTP synchronized: no
>>   RTC in local TZ: no
>>
>> How do I get the RTC to agree with the right time?
> 
> "hwclock -w" to copy the system clock to the hardware clock (RTC).  This
> should also be done during shutdown, but it doesn't hurt to do it now.
> 
> 
> On Wed, Mar 06, 2024 at 07:36:11PM +0200, Teemu Likonen wrote:
>> To get operating system's clock have accurate time it needs to be
>> synchronized with network time servers via network time protocol (NTP).
>> Systemd has that feature. Turn in on with
>>
>>      sudo timedatectl set-ntp true
> 
> But *don't* do that if you're using some other NTP program instead of
> systemd-timesyncd.  Unfortunately, timedatectl does not know about other
> NTP programs, and won't report which one you're using.  You'll have
> to find that out yourself

Are you saying that both chrony and ntpsec, which are fully ntp 
client/server ack the docs are worthless to timedatectl?

I have a quite good 3d printer, but its running armbian buster, its out 
of synch by days despite ntpsec running and I can see it access my own 
level 2 server but the timedate never synchronizes. I need to know how 
to setup timedatectl to slam the ntp time into the system clock on first 
access at bootup. That would fix a lot of bogus times reported by 
fluidd, the printers web based gui front end.

Thanks Greg. Take care & stay well.

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#268120

On Wed, Mar 06, 2024 at 05:56:29PM -0500, gene heskett wrote:
> On 3/6/24 12:42, Greg Wooledge wrote:
> > On Wed, Mar 06, 2024 at 12:31:46PM -0500, Roy J. Tellason, Sr. wrote:
> > >      sudo timedatectl set-ntp true
> > 
> > But *don't* do that if you're using some other NTP program instead of
> > systemd-timesyncd.

> Are you saying that both chrony and ntpsec, which are fully ntp
> client/server ack the docs are worthless to timedatectl?

I'm saying "don't turn on systemd's NTP thing if you're using a different
NTP thing".

Roy's instructions failed to take into account that many of us are
already using a different NTP implementation, besides systemd's.

[toc] | [prev] | [next] | [standalone]

#268121

On 3/6/24 18:02, Greg Wooledge wrote:
> On Wed, Mar 06, 2024 at 05:56:29PM -0500, gene heskett wrote:
>> On 3/6/24 12:42, Greg Wooledge wrote:
>>> On Wed, Mar 06, 2024 at 12:31:46PM -0500, Roy J. Tellason, Sr. wrote:
>>>>       sudo timedatectl set-ntp true
>>>
>>> But *don't* do that if you're using some other NTP program instead of
>>> systemd-timesyncd.
> 
>> Are you saying that both chrony and ntpsec, which are fully ntp
>> client/server ack the docs are worthless to timedatectl?
> 
> I'm saying "don't turn on systemd's NTP thing if you're using a different
> NTP thing".
> 
> Roy's instructions failed to take into account that many of us are
> already using a different NTP implementation, besides systemd's.

I can turn either off, but no place in the ntpsec docs, nor the chrony 
docs does it show the ability to slam the current time into the SW clock 
on these arm systems at bootup's first access time.  And the normal 
correction is maybe a second an hour so it its been turned off for a 
week, its another week out of time when turned back on. The whole thing 
never considered the no hwclock situation that exists in 99% of the arm 
world. I was hoping timedatectl had that ability but I see it says you 
must be synched first. The rpis's can do it, whats the secret recipe?

Thank Greg, take care & stay well.
Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#268122

Look at the chronyd settime command and the chrony.conf makestep
directive.  These are intended for your situation.
-- 
John Hasler 
john@sugarbit.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#268124

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 06, 2024 at 08:06:15PM -0600, John Hasler wrote:
> Look at the chronyd settime command and the chrony.conf makestep
> directive.  These are intended for your situation.

This from man(8) ntpd:

 -g, --panicgate
   Allow the first adjustment to be Big.  This option may appear an
   unlimited number of times.

   Normally, ntpd exits with a message to the system log if the off‐
   set exceeds the panic threshold, which is 1000 s by default. This
   option allows the time to be set to any value without restric‐
   tion; however, this can happen only once. If the threshold is ex‐
   ceeded after that, ntpd will exit with a message to the system
   log. This option can be used with the -q and -x options.  See the
   tinker configuration file directive for other options.

 -G, --force-step-once
   Step any initial offset correction..
   [...]

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#268137

On 3/7/24 00:22, tomas@tuxteam.de wrote:
> On Wed, Mar 06, 2024 at 08:06:15PM -0600, John Hasler wrote:
>> Look at the chronyd settime command and the chrony.conf makestep
>> directive.  These are intended for your situation.
> 
> This from man(8) ntpd:
> 
>   -g, --panicgate
>     Allow the first adjustment to be Big.  This option may appear an
>     unlimited number of times.
> 
>     Normally, ntpd exits with a message to the system log if the off‐
>     set exceeds the panic threshold, which is 1000 s by default. This
>     option allows the time to be set to any value without restric‐
>     tion; however, this can happen only once. If the threshold is ex‐
>     ceeded after that, ntpd will exit with a message to the system
>     log. This option can be used with the -q and -x options.  See the
>     tinker configuration file directive for other options.
> 
>   -G, --force-step-once
>     Step any initial offset correction..
>     [...]
> 
> Cheers

So I purged ntpsec and re-installed chrony which I had done once before 
with no luck but this time timedatectl was stopped and it worked!

Now, how do I assure timedatectl stays stopped on a reboot? systemd's 
docs are positively opaque about that even if they do go on for 
megabytes. Surprisingly the chrony.conf setting to use my own server 
setup on this machine making me a level 2 ntp server, magically re-appeared.

Seems like it should have a disable option to match the enable but 
playing 50 monkeys didn't find it.

Thanks take care & stay well Tomas.

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#268138

[Multipart message — attachments visible in raw view] — view raw

On Thu, Mar 07, 2024 at 08:31:16AM -0500, gene heskett wrote:

[...]

> So I purged ntpsec and re-installed chrony which I had done once before with
> no luck but this time timedatectl was stopped and it worked!

great :-)

> Now, how do I assure timedatectl stays stopped on a reboot? [...]

I'll have to leave this to others more fluent in systemd-ish.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#268142

On Thu, Mar 7, 2024 at 8:44 AM <tomas@tuxteam.de> wrote:
>
> On Thu, Mar 07, 2024 at 08:31:16AM -0500, gene heskett wrote:
>
> [...]
> Now, how do I assure timedatectl stays stopped on a reboot? [...]
>
> I'll have to leave this to others more fluent in systemd-ish.

Mask the systemd-timesyncd service. Masking is the service a permanent effect.

If you just stop or disable the service, then the service will either
be started on the next reboot, or it can be manually started. Since
you want to permanently disable the service, you have to mask it.

Jeff

[toc] | [prev] | [next] | [standalone]

#268143

On 3/7/24 11:18, Jeffrey Walton wrote:
> On Thu, Mar 7, 2024 at 8:44 AM <tomas@tuxteam.de> wrote:
>>
>> On Thu, Mar 07, 2024 at 08:31:16AM -0500, gene heskett wrote:
>>
>> [...]
>> Now, how do I assure timedatectl stays stopped on a reboot? [...]
>>
>> I'll have to leave this to others more fluent in systemd-ish.
> 
> Mask the systemd-timesyncd service. Masking is the service a permanent effect.

it appears its not installed. It can't be found to purge it. That would 
explain why it didn't work.
> 
> If you just stop or disable the service, then the service will either
> be started on the next reboot, or it can be manually started. Since
> you want to permanently disable the service, you have to mask it.
> 
> Jeff
> .
Thanks Jeff.
Take care & stay well.

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#268139

[Multipart message — attachments visible in raw view] — view raw

* 2024-03-07 08:31:16-0500, gene heskett wrote:

> So I purged ntpsec and re-installed chrony which I had done once before 
> with no luck but this time timedatectl was stopped and it worked!
>
> Now, how do I assure timedatectl stays stopped on a reboot? systemd's
> docs are positively opaque about that even if they do go on for
> megabytes.

"timedatectl" is a command for configuring and showing various time
settings. You probably mean: how to stop Systemd's NTP service. See "man
timedatectl" or "timedatectl -h". Look for subcommand "set-ntp".

    sudo timedatectl set-ntp false

See the current state with just "timedatectl" command. What happens
behind the surface is enabling/disabling service
systemd-timesyncd.service. You can check its status:

    systemctl status systemd-timesyncd.service

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462

[toc] | [prev] | [next] | [standalone]

#268156

On Thursday 07 March 2024 09:02:44 am Teemu Likonen wrote:
> systemctl status systemd-timesyncd.service

This got me some interesting results:

● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: inactive (dead)
Condition: start condition failed at Wed 2024-02-14 16:17:31 EST; 3 weeks 0 days ago
           └─ ConditionFileIsExecutable=!/usr/sbin/VBoxService was not met
     Docs: man:systemd-timesyncd.service(8)

Hmm.

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

[toc] | [prev] | [next] | [standalone]

#268157

On Thu, Mar 07, 2024 at 02:33:05PM -0500, Roy J. Tellason, Sr. wrote:
> On Thursday 07 March 2024 09:02:44 am Teemu Likonen wrote:
> > systemctl status systemd-timesyncd.service
> 
> This got me some interesting results:
> 
> ● systemd-timesyncd.service - Network Time Synchronization
>    Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
>   Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
>            └─disable-with-time-daemon.conf
>    Active: inactive (dead)
> Condition: start condition failed at Wed 2024-02-14 16:17:31 EST; 3 weeks 0 days ago
>            └─ ConditionFileIsExecutable=!/usr/sbin/VBoxService was not met
>      Docs: man:systemd-timesyncd.service(8)
> 
> Hmm.

Are you running that on a virtualbox client, or a virtualbox host?

In any case, you might find it interesting to read the unit file in
question ("systemctl cat systemd-timesyncd.service").  It looks like
you've got one of the slightly older kind, where the service is always
installed, but is prevented from running if any of several different
programs is found.

[toc] | [prev] | [next] | [standalone]

#268184

On Thursday 07 March 2024 02:44:42 pm Greg Wooledge wrote:
> On Thu, Mar 07, 2024 at 02:33:05PM -0500, Roy J. Tellason, Sr. wrote:
> > On Thursday 07 March 2024 09:02:44 am Teemu Likonen wrote:
> > > systemctl status systemd-timesyncd.service
> > 
> > This got me some interesting results:
> > 
> > ● systemd-timesyncd.service - Network Time Synchronization
> >    Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
> >   Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
> >            └─disable-with-time-daemon.conf
> >    Active: inactive (dead)
> > Condition: start condition failed at Wed 2024-02-14 16:17:31 EST; 3 weeks 0 days ago
> >            └─ ConditionFileIsExecutable=!/usr/sbin/VBoxService was not met
> >      Docs: man:systemd-timesyncd.service(8)
> > 
> > Hmm.
> 
> Are you running that on a virtualbox client, or a virtualbox host?

That was on the host.  The client is running an older version of Slackware.
 
> In any case, you might find it interesting to read the unit file in
> question ("systemctl cat systemd-timesyncd.service").  It looks like
> you've got one of the slightly older kind, where the service is always
> installed, but is prevented from running if any of several different
> programs is found.
 
Yes,  I'm running older software here.  I did that and see those listed near the end of it.  The system does seem to do okay with keeping the right time,  though,  for the most part.  The only rough spot was the RTC was way off,  but that's now been fixed... 


-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web