This bug was fixed in the package chrony - 3.2-4ubuntu2
---
chrony (3.2-4ubuntu2) bionic; urgency=medium
* Set -x as default if unable to set time (e.g. in containers) (LP: #1589780)
Chrony is a single service which acts as both NTP client (i.e. syncing the
local clock) and
** Merge proposal unlinked:
https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/341461
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1589780
Title:
chrony.service
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/341461
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1589780
Title:
chrony.service doesn't
Pre-Checks:
- Message on install only visible in container
- Service running in default conf after install in container and Metal
- Warnings that this is a non syncing fallback emphasized in log (log level
recognized)
- -x added in container as default.
- Warnings/Fallback skipped if manual -x is
>From the ML discussions upstream might take the initialization improvements,
>but not the try-and-fall-back we need.
So we will go with the wrapper for now.
There might be a best of both worlds approach to make us safe against time
namespaces.
We could use the wrapper to set -X (upper case)
Note: while the wrapper approach would work (after some test and
polishing), compared to the upstream -X it will have one drawback.
If future containers grow time-namespacing as a feature it will still default
to not adjusting the time in containers.
But as long as we don't know how
In case upstream won't accept the changes, here he revised Design of the
wrapper as mentioned in comment #9:
- The amount of "-x" passed to chronyd doesn't matter, so we can just add one.
- But OTOH the X-SET check is good and can be used to silence the warnings we
otherwise would
emit
With discussions ongoing a new option came up.
Upstream doesn't really see the case for -X yet, but we can't maintain
it reasonably for what we need it without that upstream. (we can do it
in shell wrappers, but that is a huge maintenance debt and fails as it
can never fully test if it can adjust
FYI - New patches sent upstream, discussion ongoing.
V1 - https://www.mail-archive.com/chrony-dev@chrony.tuxfamily.org/msg01807.html
V2 - https://www.mail-archive.com/chrony-dev@chrony.tuxfamily.org/msg01829.html
V3 - https://www.mail-archive.com/chrony-dev@chrony.tuxfamily.org/msg01832.html
--
FYI - upstream discussion goes on, maybe we find a way that works better, but
is less hacky.
I'll update here once we settled on something there.
OTOH - everybody interested on this is invited to chime in there.
For the mail archive of it see:
I summarized the above in a reply to upstream, since we have different
places to implement I'd pick the one they prefer and also hear their
opinion in general.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Discussion went back and forth upstream as well as with people on the bug.
Trying to summarize:
For upstream it is not reasonable to "silently" do not work as expected - and
that is correct.
There was a discussion on a "Fallback if unable to set it" option as an
alternative.
But even that you
I resubmitted to -dev instead of -user, which is more correct for the patch
anyway.
Lets see if it shows up there ...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1589780
Title:
chrony.service
And there it is
https://www.mail-archive.com/chrony-dev@chrony.tuxfamily.org/msg01807.html
Of course now it shows up on both :-/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1589780
Title:
I submitted upstream, but still don't see it in the archive.
I'm subscribed and got no reject or such, so I wonder what I miss ...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1589780
Title:
Note: I now also implemented it trying to follow the usual chrony
generic/OSType split as I hope this will make it more acceptable.
WIP Test PKG is available in PPA:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3188
Tests:
1. starts in container if -x is set in
I had the attached wrapper and it worked, but it feels wrong to solve it that
way.
Instead (plan) I'm gonna implement in C instead.
I think it will be after getopt checking cap_sys_time and imply -x if not
available.
I plan to suggest so upstream, if accepted I'll apply.
Otherwise for now we
Two system files are stupid for not being able to have a single name.
But a wrapper will work.
We can have one service, drop the Condition off the current .service.
And then the wrapper can add -x if running without cap_sys_time.
It can also make sure there is no -x already in DAEMON_OPTS and
Thanks to Vincent Blut I was pointed to [1]
That pretty much looks like the patch I was going to write, thanks a lot
Vincent!
There are some extra needs, to actually start in a container, but maybe
those are upstream as well - I'll check that.
Otherwise my plan would be to somehow match on
So far it only has uid/gid, call chain is
main
/* Drop root privileges if the specified user has a non-zero UID */
if (!geteuid() && (pw->pw_uid || pw->pw_gid))
SYS_DropRoot(pw->pw_uid, pw->pw_gid);
->
SYS_DropRoot (maps to implementations)
->
It seems that on priv-drop (independent to -x) it wants to keep privs for
certain things.
Essentially ntp only if it binds, but cap_sys_time it wants always.
SYS_Linux_DropRoot(uid_t uid, gid_t gid)
{
const char *cap_text;
cap_t cap;
if (prctl(PR_SET_KEEPCAPS, 1)) {
LOG_FATAL("prctl()
I started a discussion upstream, but afterwards on tests realized that even
then it fails with:
cap_set_proc() failed
Need to look into that a bit deeper ...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Changed in: chrony (Ubuntu)
Assignee: (unassigned) => ChristianEhrhardt (paelzer)
** Changed in: chrony (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I'm re-opening this. As per the previous comments, chrony indeed doesn't
work inside a container because it fails to set the time of the local
system, it crashes, and fails to start.
However, chrony should be able to run just fine inside a container even
if it cannot set the time of the local
It seems not possible a container to have its own system time being managed.
http://lwn.net/Articles/179825/
There seemed a patch as above for time namespace, but it seems rejected.
** Changed in: chrony (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you
ntp seems to have the similar issue but does not stop the service.
Since LXC container is limited to access kernel variables, it might be
difficult to make it.
sudo systemctl status ntp
● ntp.service - LSB: Start NTP daemon
Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled)
26 matches
Mail list logo
