[ 
https://issues.apache.org/jira/browse/KUDU-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16003482#comment-16003482
 ] 

Miklos Szegedi commented on KUDU-2000:
--------------------------------------

Docker has another filter. I think the bug is here:
https://github.com/moby/moby/blob/master/profiles/seccomp/seccomp_default.go
{code}
                {
                        Names: []string{
                                "settimeofday",
                                "stime",
                                "adjtimex",
                                "clock_settime",
                        },
                        Action: types.ActAllow,
                        Args:   []*types.Arg{},
                        Includes: types.Filter{
                                Caps: []string{"CAP_SYS_TIME"},
                        },
                },
}
{code}

I think it should be rather something like the following to allow modes=0
{code}
                {
                        Names:  []string{"adjtimex"},
                        Action: types.ActAllow,
                        Args: []*types.Arg{
                                {
                                        Index: 0,
                                        Value: 0,
                                        Op:    types.OpEqualTo,
                                },
                        },
                },
{code}

> Kudu requires CAP_SYS_TIME capability in Linux Docker containers
> ----------------------------------------------------------------
>
>                 Key: KUDU-2000
>                 URL: https://issues.apache.org/jira/browse/KUDU-2000
>             Project: Kudu
>          Issue Type: Bug
>    Affects Versions: 1.3.1
>            Reporter: Mike Percy
>
> When running Kudu in a Docker container, Kudu currently requires the 
> CAP_SYS_TIME capability (or running the docker container with the 
> --privileged flag).
> If run with default privileges, calling ntp_gettime() results in an EPERM 
> error that apparently comes from adjtimex(). In that case, the resulting 
> fatal error from HybridTime looks like the following in the logs:
> {code}
> F0508 22:36:35.687885     1 master_main.cc:68] Check failed: _s.ok() Bad 
> status: Service unavailable: Cannot initialize clock: Error reading clock. 
> ntp_gettime() failed: Operation not permitted
> *** Check failure stack trace: ***
> *** Aborted at 1494282995 (unix time) try "date -d @1494282995" if you are 
> using GNU date ***
> PC: @     0x7f6696f2c1d7 __GI_raise
> *** SIGABRT (@0x1) received by PID 1 (TID 0x7f66992a9940) from PID 1; stack 
> trace: ***
>     @     0x7f6698c66370 (unknown)
>     @     0x7f6696f2c1d7 __GI_raise
>     @     0x7f6696f2d8c8 __GI_abort
>     @          0x1961719 (unknown)
>     @           0x843a9d google::LogMessage::Fail()
>     @           0x845a43 google::LogMessage::SendToLog()
>     @           0x8435f9 google::LogMessage::Flush()
>     @           0x8463cf google::LogMessageFatal::~LogMessageFatal()
>     @           0x7e9c23 (unknown)
>     @     0x7f6696f18b35 __libc_start_main
>     @           0x7e9629 (unknown)
>     @                0x0 (unknown)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to