ntpd at securelevel 2?

I'd like to run ntpd on 3.0/sparc to keep time in sync.
Using the stock /etc/ntp.conf, ntpd comes up and 'ntpq -c
peers' shows 
something useful, but after a few minutes, ntpd starts
burning CPU time, 
and ktrace says:

   5771 ntpd     clock_settime(0, 0xefffdbc0)       Err#1
EPERM
   5771 ntpd     geteuid()                          = 0, -1
   5771 ntpd     clock_settime(0, 0xefffdbc0)       Err#1
EPERM
   5771 ntpd     geteuid()                          = 0, -1
   ...

infinitely. Accoring to the init(8) manpage, securelevel 2
restricts the 
settimeofday(2) call only.

FWIW, the kernel does have options NTP and pseudo-device
clockctl, and 
/dev/clockctl does exist.

Is there anything obvious I'm missing?


  - Hubert

Hubert Feyrer wrote:
> I'd like to run ntpd on 3.0/sparc to keep time in
sync.
> Using the stock /etc/ntp.conf, ntpd comes up and 'ntpq
-c peers' shows 
> something useful, but after a few minutes, ntpd starts
burning CPU 
> time, and ktrace says:
>
>   5771 ntpd     clock_settime(0, 0xefffdbc0)      
Err#1 EPERM
>   5771 ntpd     geteuid()                          = 0,
-1
>   5771 ntpd     clock_settime(0, 0xefffdbc0)      
Err#1 EPERM
>   5771 ntpd     geteuid()                          = 0,
-1
>   ...
>
> infinitely. Accoring to the init(8) manpage,
securelevel 2 restricts 
> the settimeofday(2) call only.
>
> FWIW, the kernel does have options NTP and
pseudo-device clockctl, and 
> /dev/clockctl does exist.
>
> Is there anything obvious I'm missing?

If the clock is far enough off that it needs to step the
time by setting 
it, rather than using adjtime(), running at a high
securelevel will 
prevent ntpd from doing so.  Reboot the system with a lower
securelevel 
until the clock is synced, and then try again at a higher
securelevel.

It's possible the -x flag to ntpd will help, too....

-- 
-Chuck

On Mon, 29 May 2006, Chuck Swiger wrote:
> If the clock is far enough off that it needs to step
the time by setting it, 
> rather than using adjtime(), running at a high
securelevel will prevent ntpd 
> from doing so.  Reboot the system with a lower
securelevel until the clock is 
> synced, and then try again at a higher securelevel.

hrm, shouldn't ntpdate take care of that, upon boot?


> It's possible the -x flag to ntpd will help, too....

I'll try that one, so far it looks promising.
Thanks!


  - Hubert

On May 30, 2006, at 4:58 AM, Hubert Feyrer wrote:
> On Mon, 29 May 2006, Chuck Swiger wrote:
>> If the clock is far enough off that it needs to
step the time by  
>> setting it, rather than using adjtime(), running at
a high  
>> securelevel will prevent ntpd from doing so. 
Reboot the system  
>> with a lower securelevel until the clock is synced,
and then try  
>> again at a higher securelevel.
>
> hrm, shouldn't ntpdate take care of that, upon boot?

Yeah, if ntpdate runs before the securelevel gets
elevated...?

>> It's possible the -x flag to ntpd will help,
too....
>
> I'll try that one, so far it looks promising.
> Thanks!

You're welcome.  Just try to get the clock synced
reasonably close  
before trying "-x", or else it may take an
excessive amount of time  
to get synced using adjtime()...

-- 
-Chuck