On Wed, May 23, 2018 at 4:25 PM, Miroslav Lichvar <mlich...@redhat.com>
wrote:
> On Wed, May 23, 2018 at 04:06:31PM +0200, Christian Ehrhardt wrote:
> > First of all I'll like the simplification - so thanks for working on
> this.
> > Is the expected usage then an unc
On Thu, May 24, 2018 at 2:45 PM, Miroslav Lichvar <mlich...@redhat.com>
wrote:
> On Thu, May 24, 2018 at 02:11:58PM +0200, Christian Ehrhardt wrote:
> > On auto-deployed config changes of virt systems (with plenty of switch
> > interfaces for example) I've seen three di
On Thu, May 24, 2018 at 11:54 AM, Miroslav Lichvar <mlich...@redhat.com>
wrote:
> On Wed, May 23, 2018 at 04:44:30PM +0200, Christian Ehrhardt wrote:
> > No I'm fine with a single command.
> > If it is low on cpu consumption and fast.
> > We have to consider that in s
.tuxfamily.org with "help" in the
> subject.
> Trouble? Email listmas...@chrony.tuxfamily.org.
>
>
--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
On Thu, Mar 8, 2018 at 10:14 AM, Miroslav Lichvar <mlich...@redhat.com>
wrote:
> On Wed, Mar 07, 2018 at 04:43:20PM +0100, Christian Ehrhardt wrote:
> > I thought that having the server portion work by default would be very
> nice
> > to user.
>
> Are there any
On Thu, Mar 8, 2018 at 1:49 PM, Miroslav Lichvar <mlich...@redhat.com>
wrote:
> On Thu, Mar 08, 2018 at 12:21:16PM +0100, Christian Ehrhardt wrote:
> > 1. if you are in a container you very likely can't set the time.
> > Installing chrony there would silently not sta
On Thu, Mar 8, 2018 at 3:52 PM, Miroslav Lichvar <mlich...@redhat.com>
wrote:
> On Thu, Mar 08, 2018 at 03:15:36PM +0100, Christian Ehrhardt wrote:
> > On Thu, Mar 8, 2018 at 1:49 PM, Miroslav Lichvar <mlich...@redhat.com>
> > > But this is what users expect i
On Thu, Mar 8, 2018 at 6:09 PM, Miroslav Lichvar <mlich...@redhat.com>
wrote:
> On Thu, Mar 08, 2018 at 05:08:16PM +0100, Christian Ehrhardt wrote:
> > 1. the option would not be default on, so "normal" users/installations
> > would not be affected
> > 2.
Trouble? Email listmas...@chrony.tuxfamily.org.
>>
>>
>>
>>
>> --
>> Christian EhrhardtSoftware Engineer, Ubuntu Server
>> Canonical Ltd
>>
>>
>>
>>
>> --
>> Christian EhrhardtSoftware Engineer, Ubuntu Server
>> Canonical Ltd
>>
>>
>>
>>
>> --
>> Christian EhrhardtSoftware Engineer, Ubuntu Server
>> Canonical Ltd
>>
>>
--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
e behavior
if needed, without loosing the feature to control time when running in an
environment that is able to do so.
Signed-off-by: Christian Ehrhardt <christian.ehrha...@canonical.com>
---
doc/chronyd.adoc | 7 +++
examples/chronyd.service | 1 -
main.c
as well, but handle the effecive behavior via -x/-X (or
none of these).
This allows a much more visual explanation of why the service doesn't
run.
Signed-off-by: Christian Ehrhardt <christian.ehrha...@canonical.com>
---
doc/chronyd.adoc | 7 +++
examples/chronyd.service | 1 -
mai
On Tue, Mar 13, 2018 at 11:29 AM, Miroslav Lichvar <mlich...@redhat.com>
wrote:
> On Tue, Mar 13, 2018 at 10:45:56AM +0100, Christian Ehrhardt wrote:
> > In unprivileged containers even after e8096330 "sys_linux: don't keep
> > CAP_SYS_TIME with -x option" default i
On Tue, Mar 13, 2018 at 2:50 PM, Miroslav Lichvar <mlich...@redhat.com>
wrote:
> On Tue, Mar 13, 2018 at 12:17:41PM +0100, Christian Ehrhardt wrote:
> > The important part is the lack of knowledge of the target systems
> > capabilities.
> > They are:
> > - not
On Tue, Mar 13, 2018 at 4:02 PM, Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:
>
>
> On Tue, Mar 13, 2018 at 2:50 PM, Miroslav Lichvar <mlich...@redhat.com>
> wrote:
>
>> On Tue, Mar 13, 2018 at 12:17:41PM +0100, Christian Ehrhardt wrote:
&g
On Tue, Mar 13, 2018 at 5:24 PM, Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:
>
>
> On Tue, Mar 13, 2018 at 4:02 PM, Christian Ehrhardt <
> christian.ehrha...@canonical.com> wrote:
>
>>
>>
>> On Tue, Mar 13, 2018 at 2:50 PM, Mi
On Wed, Mar 14, 2018 at 11:42 AM, Miroslav Lichvar <mlich...@redhat.com>
wrote:
> On Wed, Mar 14, 2018 at 11:16:10AM +0100, Christian Ehrhardt wrote:
> > On Wed, Mar 14, 2018 at 11:01 AM, Miroslav Lichvar <mlich...@redhat.com>
> > wrote:
> > > At this time,
quot;);
> > +} else {
> > + LOG(LOGS_WARN, "Falling back by disabling control of the system
> clock");
>
> I'd remove these messages.
>
> > +void SYS_Linux_ReportTimeAdjustBlockers(void)
> > +{
> > + if (CAP_IS_SUPPORTED(CAP_SYS_TIME) && cap_get_bound(CAP_SYS_TIME))
> > +return;
> > + LOG(LOGS_WARN, "CAP_SYS_TIME not present");
> > +}
>
> Could this be included (and wrapped in FEAT_PRIVDROP) in
> SYS_Linux_Initialise()?
>
> Thanks,
>
> --
> Miroslav Lichvar
>
> --
> To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with
> "unsubscribe" in the subject.
> For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the
> subject.
> Trouble? Email listmas...@chrony.tuxfamily.org.
>
>
--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
On Fri, Mar 9, 2018 at 8:18 AM, Miroslav Lichvar <mlich...@redhat.com>
wrote:
> On Thu, Mar 08, 2018 at 06:09:00PM +0100, Miroslav Lichvar wrote:
> > On Thu, Mar 08, 2018 at 05:08:16PM +0100, Christian Ehrhardt wrote:
> > > 1. the option would not be default on, so &quo
On Thu, Mar 8, 2018 at 4:34 PM, Miroslav Lichvar <mlich...@redhat.com>
wrote:
> On Thu, Mar 08, 2018 at 04:20:48PM +0100, Christian Ehrhardt wrote:
> > On Thu, Mar 8, 2018 at 3:52 PM, Miroslav Lichvar <mlich...@redhat.com>
> > wrote:
> > > I'd rather k
are tightly coupled and need each
other in the code that solution isn't anywhere close either.
[1]: http://man7.org/linux/man-pages/man7/user_namespaces.7.html
Christian Ehrhardt (3):
sys_linux: report if CAP_SYS_TIME is not present
sys: rework initialisation to return a value
main: add -
this allow further patches to plug-in a generic fallback
mechanism at the level os SYS_Initialise.
Messages will now look like:
CAP_SYS_TIME not present
adjtimex(0x8001) failed : Operation not permitted
Could not initialise system clock driver
Signed-off-by: Christian Ehrhardt <christian.eh
extend this can also be seen as an ntpd compat option which
complained in syslog but did not crash under these conditions.
Signed-off-by: Christian Ehrhardt <christian.ehrha...@canonical.com>
---
doc/chronyd.adoc | 8
main.c | 5 -
sys.c| 7 +++
3 files ch
Signed-off-by: Christian Ehrhardt <christian.ehrha...@canonical.com>
---
sys_linux.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/sys_linux.c b/sys_linux.c
index f445727..7848816 100644
--- a/sys_linux.c
+++ b/sys_linux.c
@@ -381,6 +381,15 @@ test_step_offse
On Wed, Mar 14, 2018 at 3:32 PM, Miroslav Lichvar <mlich...@redhat.com>
wrote:
> On Wed, Mar 14, 2018 at 03:05:29PM +0100, Christian Ehrhardt wrote:
> > Instead of having adjtimex just fail with a permission issue
> > improve the error messaging by warning for the lac
On Fri, Dec 6, 2019 at 7:19 PM Vincent Blut wrote:
> On 2019-12-06T16:55+0100, Vincent Blut wrote:
> >On 2019-12-06T10:21+0100, Christian Ehrhardt wrote:
> >>Hi chrony-dev,
> >>chrony is tested in Debian/Ubuntu on any update of related packages
> >>and while
the test and skip
if it is unable to use it.
Signed-off-by: Christian Ehrhardt
---
test/system/101-rtc | 1 +
1 file changed, 1 insertion(+)
diff --git a/test/system/101-rtc b/test/system/101-rtc
index fa9a70d..cbffd1c 100755
--- a/test/system/101-rtc
+++ b/test/system/101-rtc
@@ -4,6 +4,7
On Tue, Dec 10, 2019 at 12:20 PM Miroslav Lichvar
wrote:
> On Fri, Dec 06, 2019 at 12:35:21PM +0100, Christian Ehrhardt wrote:
> > To summarize:
> > - RTC init fails
> > - SCH_MainLoop then hangs
> > Could the second be a consequence of the first?
> > Does this m
On Wed, Dec 11, 2019 at 5:42 PM Miroslav Lichvar
wrote:
> On Wed, Dec 11, 2019 at 04:13:23PM +0100, Christian Ehrhardt wrote:
> > That means the first switch_interrupts call from RTC_Initialise ->
> > RTC_Linux_Initialise -> switch_interrupts has on_off=0 and that doesn't
check on 101-rtc to accept
that condition as a valid test result as well.
Signed-off-by: Christian Ehrhardt
---
test/system/101-rtc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/system/101-rtc b/test/system/101-rtc
index fa9a70d..68bce68 100755
--- a/test/system/101-rtc
[ 0.876198] rtc-efi rtc-efi: registered as rtc0
[ 1.046869] rtc-efi rtc-efi: setting system clock to ...
Signed-off-by: Christian Ehrhardt
---
rtc_linux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rtc_linux.c b/rtc_linux.c
index aee768f..a44a912 100644
--- a/rtc_linux.c
+++ b
in v2:
- reduce the check to work if the error messages are internationalized
- add check to cover RTCs only misbehaving on enabling IRQs
Christian Ehrhardt (2):
test: accept test if platform is unable of RTC is RTC_UIE_ON
rtc: extend check for RTCs that don't support interrupts
rtc_linux.c
[ 0.270221] rtc-generic rtc-generic: setting system clock to ...
ARM64# dmesg | grep -i rtc
[ 0.876198] rtc-efi rtc-efi: registered as rtc0
[ 1.046869] rtc-efi rtc-efi: setting system clock to ...
Signed-off-by: Christian Ehrhardt
---
rtc_linux.c | 2 +-
1 file changed, 1 insertion(+), 1
the test and skip
if it is unable to use it.
Output generally looks like:
ioctl(4, RTC_UIE_ON, 0): Invalid argument
But for internationalization only compare the left part of it.
In the good case this line won't show up at all.
Signed-off-by: Christian Ehrhardt
---
test/system/101-rtc | 1 +
1
is what is broken).
Updates in v2:
- reduce the check to work if the error messages are internationalized
- add check to cover RTCs only misbehaving on enabling IRQs
Christian Ehrhardt (2):
test: check if RTC is RTC_UIE_ON capable
rtc: extend check for RTCs that don't support interrupts
On Tue, Dec 10, 2019 at 5:59 PM Miroslav Lichvar
wrote:
> On Tue, Dec 10, 2019 at 04:25:31PM +0100, Christian Ehrhardt wrote:
> > On Tue, Dec 10, 2019 at 4:19 PM Miroslav Lichvar
> > > I'm sorry for changing my mind, but I now think this case should be
> > > ha
On Wed, Dec 11, 2019 at 4:24 PM Vincent Blut wrote:
> On 2019-12-11T16:13+0100, Christian Ehrhardt wrote:
> >On Tue, Dec 10, 2019 at 5:59 PM Miroslav Lichvar
> >wrote:
> >
> >> On Tue, Dec 10, 2019 at 04:25:31PM +0100, Christian Ehrhardt wrote:
> >> >
ian.org/debian/chrony/blob/master/debian/tests/upstream-system-tests
[4]: https://salsa.debian.org/debian/chrony/merge_requests/2
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe"
in the sub
On Fri, Dec 6, 2019 at 11:32 AM Vincent Blut wrote:
>
> Hi Christian,
>
> On 2019-12-06T10:21+0100, Christian Ehrhardt wrote:
> >Hi chrony-dev,
> >chrony is tested in Debian/Ubuntu on any update of related packages
> >and while that was running I found that arm64 and
> >
> > Could that be due to the use of “-x”? IFAIR you have extra stuff on
> > Ubuntu about that option.
>
> I was testing the current master tarball from upstream to avoid any confusion.
> => https://git.tuxfamily.org/chrony/chrony.git/snapshot/chrony-master.tar.gz
>
> That exposes the same
On Fri, Dec 6, 2019 at 12:51 PM Vincent Blut wrote:
>
> On 2019-12-06T12:35+0100, Christian Ehrhardt wrote:
> >> >
> >> > Could that be due to the use of “-x”? IFAIR you have extra stuff on
> >> > Ubuntu about that option.
> >>
> >> I w
On Tue, Dec 10, 2019 at 4:06 PM Vincent Blut wrote:
> On 2019-12-10T15:52+0100, Christian Ehrhardt wrote:
> >The test might run on different platforms.
> >If the platform happens to have a RTC that does exist but unable to
> >have RTC_UIE_ON set the test will fall
On Tue, Dec 10, 2019 at 4:19 PM Miroslav Lichvar
wrote:
> On Tue, Dec 10, 2019 at 04:11:14PM +0100, Christian Ehrhardt wrote:
> > On Tue, Dec 10, 2019 at 4:06 PM Vincent Blut
> wrote:
> > > >+hwclock -r --test | grep -q '^ioctl.*RTC_UIE_ON.*Invalid argument$'
&
u...@chrony.tuxfamily.org with "help" in the
> subject.
> Trouble? Email listmas...@chrony.tuxfamily.org.
>
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe"
in the subje
; >has the latest glibc, right? If the test suite passes on all those
> >archs, hopefully the seccomp rules will hold for a while.
>
> It will go into experimental, indeed. However, for unknown reasons,
> we’re still stuck with glibc 2.31.
When Vincent (thanks in advance!) has t
ily.org with
> "unsubscribe" in the subject.
> For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the
> subject.
> Trouble? Email listmas...@chrony.tuxfamily.org.
>
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
--
To
On Thu, Mar 25, 2021 at 1:32 PM Miroslav Lichvar wrote:
>
> On Thu, Mar 25, 2021 at 01:13:39PM +0100, Christian Ehrhardt wrote:
> > I was able to confirm that disabling LTO resolved the issue, so for
> > now that will stay disabled on s390x. But I wanted to ask here if
> &
O.
FYI: See [1] for the related Ubuntu bug and the strange trip until I
found it indeed was LTO.
[1]: https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1921377
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org wi
(-100, 0xffdbcc3c, 0xffdbcb50, 0)
0.000821 --- SIGSYS (Bad system call) ---
Current armhf syscalls from:
https://github.com/torvalds/linux/blob/v5.10/arch/arm/tools/syscall.tbl
Signed-off-by: Christian Ehrhardt
---
sys_linux.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sys_linux.c b
-February/136040.html
Tested-by: Christian Ehrhardt
Reviewed-by: Christian Ehrhardt
Signed-off-by: Michael Hudson-Doyle
Signed-off-by: Christian Ehrhardt
---
sys_linux.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sys_linux.c b/sys_linux.c
index 9cab2efa..1b9ba5f8 100644
-by: Christian Ehrhardt
Reviewed-by: Christian Ehrhardt
Signed-off-by: Michael Hudson-Doyle
---
sys_linux.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sys_linux.c b/sys_linux.c
index 9cab2efa..1b9ba5f8 100644
--- a/sys_linux.c
+++ b/sys_linux.c
@@ -601,6 +601,9
break chrony in seccomp isolation.
>
> Applied, thanks! I just moved the new entry from the "Miscellaneous"
> group to the "Process" group which already has some thread and signal
> specific syscalls.
Sounds right, thank you Miroslav
> --
> Miroslav Lichvar
51 matches
Mail list logo
