Xterm shows in 3.10

#21

I’m not quite following what you are trying to solve for with timesymc quickly on network up. What is the use case?

I believe if its the first time it’s connected to the net that bootup, it would try to sync time faster.That’s the time it’s most likely to be off by a good amount (AFAICT).

#22

You’re right. I thought there was more reasoning behind the ntp behaviour that we implemented, but I checked and really its just for the case you describe. And timesync does a fine job there - it has a poll interval of around 30 seconds from startup, which only increases once it gets a valid response from an NTP server. This means the time gets corrected within 30 secs of establishing the first internet-enabled network connection after boot. (That’s better than the auto-restarted ntpd which took 4mins30 in my test - although I thought we had made it quicker at one point)

I think that means we can and should proceed with replacing ntpd with timesyncd. Also, looking at the docs I see that timesyncd could also replace fake-hwclock, which we had adopted and tweaked according to:

  1. On always-offline systems with no battery backed RTC, the clock is monotonic and always advances forward, even after reboot and replugging the power.
  2. On such systems, the clock is set to a date that is more accurate than just defaulting to 1970-01-01 (by setting it to the build time of a particular component, at least we’re correct within 5 years or so)
  3. If the time got set to the future, and fake-hwclock saved this to disk, it should allow the user to reset the time to the present, without always moving the time forward again. This was an old bug in fake-hwclock that we helped address in Debian.
  4. (Save the time to disk periodically, not just on shutdown. However the reasons for doing this no longer stand, this consideration can be dropped.)

timesyncd almost does the same thing, except for it will only save the time on shutdown if it got the time from a NTP server. Maybe that can be improved in future (https://github.com/systemd/systemd/issues/10620). Until that happens, I believe that if we just added touch /var/lib/systemd/timesync/clock in an appropriate shutdown script/service then we would achieve the desired behaviour (timesyncd will read and apply this on next boot).

If you have time to continue driving this, I think the next steps are:

  1. Restore our systemd debian build bits back to the Debian default (or is this what your pull request already does?)
  2. Ensure timesyncd is installed through a standard dependency chain, if not then add it to eos-meta
  3. Add the shutdown timestamp tweak described above in an appropriate place
  4. Remove ntpd and fake-hwclock from eos-meta
#23
  1. Restore our systemd debian build bits back to the Debian default (or is this what your pull request already does?)

Indeed, from what I could tell it’s just a dependency change.

  1. Ensure timesyncd is installed through a standard dependency chain, if not then add it to eos-meta

Can do.

  1. Add the shutdown timestamp tweak described above in an appropriate place
  2. Remove ntpd and fake-hwclock from eos-meta

fake-hwclock might still make sense for now, but I’m happy to re-evaluate it once timesyncd is working.

#24
  1. Restore our systemd debian build bits back to the Debian default (or is this what your pull request already does?)

Done via https://github.com/endlessm/systemd/pull/132 and https://github.com/endlessm/systemd/pull/133. Thanks @BryanQuigley!

  1. Ensure timesyncd is installed through a standard dependency chain, if not then add it to eos-meta

I just checked this in a VM and systemd-timesyncd is only automatically pulled in if ntp is not installed. Then, if ntp is re-installed systemd-timesyncd will be removed.

During an ostree build systemd-timesyncd will be pulled early in the process (systemd gets installed by mmbootstrap pretty early in the ostree build process), but once ntp is installed it will be removed. So we need to drop ntp from eos-meta to achieve this point.

  1. Add the shutdown timestamp tweak described above in an appropriate place

WIP on https://github.com/systemd/systemd/pull/20142 (related issue https://github.com/systemd/systemd/issues/10620)

  1. Remove ntpd and fake-hwclock from eos-meta

I think we need to wait for the PR above to be merged and make to our downstream repo (it may be worth backporting it) before removing fake-hwclock.

We should remove ntp right away so new ostrees use systemd-timesyncd, and we also need to drop disabling it in our units preset file in eos-boot-helper. This have been taken care by https://github.com/endlessm/eos-meta/pull/697 and https://github.com/endlessm/eos-boot-helper/pull/351.

Finally, we also need to create a systemd-timesync user in base-passwd, taken care by https://github.com/endlessm/base-passwd/pull/21.

#25

Finally, we also need to create a systemd-timesync user in base-passwd, taken care by https://github.com/endlessm/base-passwd/pull/21.

Actually, I forgot we moved base-passwd from github to being maintained directly in OBS, so that PR does not mean anything. I have submitted the equivalent change to the right place now.

#26

Just to wrap up the original topic of this thread: we found and fixed the existing mechanism in Debian’s gnome-session + gnome-menus packages that will hide the XTerm launchers. This didn’t make it into the first round of eos4 betas but should be fixed in nightly builds now.

Edit For the curious, this is the fix. Although the subject & commit message refer to Wayland, in fact the bug affected X11 as well, at least on Endless OS.

#27

Looks good - everything in this thread is now covered. Thanks!