ora legale

[Trotto@81]

Invece il serverino ha un cron che ogni ora lancia ntpdate per aggiornare l'orario!! Quello si è aggiornato al primo scattare dell'ora!!

ntpdate e` deprecato,
in /etc/rc.d/rc.local
/usr/sbin/ntpd -g -q
man ntpd
per il perche' delle opzioni usate.
In crontab:
mm,mm * * * * /usr/sbin/ntpd -g -q > /dev/null 2>&1
mm,mm p.e. 14,44, diversi per ogni macchina.

Non richiede la specificazione di nessun server?

[Mario Vanoni]

Invece il serverino ha un cron che ogni ora lancia ntpdate per aggiornare l'orario!! Quello si è aggiornato al primo scattare dell'ora!!

ntpdate e` deprecato,
in /etc/rc.d/rc.local
/usr/sbin/ntpd -g -q
man ntpd
per il perche' delle opzioni usate.
In crontab:
mm,mm * * * * /usr/sbin/ntpd -g -q > /dev/null 2>&1
mm,mm p.e. 14,44, diversi per ogni macchina.

Non richiede la specificazione di nessun server?

/etc/ntp.conf
server ch.pool.ntp.org

uso la Svizzera che ha il doppio di server attivi ed
un decimo di popolazione in confronto a it.pool.ntp.org,
http://www.pool.ntp.org/zone/europe
oggi 43 contro 16, quindi chi e` piu` accessibile?

[Trotto@81]

/etc/ntp.conf
server ch.pool.ntp.org

uso la Svizzera che ha il doppio di server attivi ed
un decimo di popolazione in confronto a it.pool.ntp.org,
http://www.pool.ntp.org/zone/europe
oggi 43 contro 16, quindi chi e` piu` accessibile?

La prima che hai detto!!

[targzeta]

boot in xp... un'ora avanti
boot in vista... un'altra ora avanti
...

, anche a me suonava strano che potesse capire da solo se l'orologio è già stato spostato, in questi casi credo ci sia bisogno di un BIOS intelligente più che del S.O.

Spina

[targzeta]

Anche io ci ho sempre capito poco tra UTC e localtime, ed anche io ho 'localtime' e come time zone 'Europe/Rome'. Ma penso che il problema sia più che altro:"chi fa chi?" cioè, chi è che si dovrebbe occupare di spostare l'orologio? Ora non ho slackware sotto mano e i miei script di init sono tutti personalizzati, io so che il mio orologio non verrà spostato (sincronizzo in automatico l'orologio sempre con ntpd una volta connesso alla rete). Però se date uno sguardo agli script /etc/rc.d secondo me troviamo la risposta al problema.

Spina

@jimmy_page_89, anche le distribuzioni linux hanno il log degli accessi, non demonizziamo Windows più di quanto non facciano già quelli della Microsoft .
Il problema è: mettiti nei panni di windows (o di un qualunque altro S.O.), come faresti ad accorgerti che l'orologio è già stato spostato?

[Mario Vanoni]

Anche io ci ho sempre capito poco tra UTC e localtime, ed anche io ho 'localtime' e come time zone 'Europe/Rome'. Ma penso che il problema sia più che altro:"chi fa chi?" cioè, chi è che si dovrebbe occupare di spostare l'orologio?

Idem, localtime ed Europe/Rome, ma in crontab ho in piu`

54 13,19 * * * /sbin/hwclock --systohc --localtime --noadjfile > /dev/null 2>&1

che aggiorna due volte al giorno l'orologio della mobo.

[targzeta]

...Idem, localtime ed Europe/Rome, ma in crontab ho in piu`

54 13,19 * * * /sbin/hwclock --systohc --localtime --noadjfile > /dev/null 2>&1

che aggiorna due volte al giorno l'orologio della mobo.

Io l'orologio del bios lo aggiorno allo shutdown.

Spina

[Mario Vanoni]

...Idem, localtime ed Europe/Rome, ma in crontab ho in piu`

54 13,19 * * * /sbin/hwclock --systohc --localtime --noadjfile > /dev/null 2>&1

che aggiorna due volte al giorno l'orologio della mobo.

Io l'orologio del bios lo aggiorno allo shutdown.

Spina

Riuscendo a bloccare una macchina con
EXT2-fs error (device sda1): ext2_get_inode: unable to read inode block - inode=46612508, block=186449923
EXT2-fs error (device sda1): ext2_free_branches: Read failure, inode=46612508, block=186449923
Interruttore ultima ratio

preferisco la mia soluzione, al boot tempo aggiornato +/- qualche secondo.

[anycolouryoulike]

Anche io ci ho sempre capito poco tra UTC e localtime, ed anche io ho 'localtime' e come time zone 'Europe/Rome'. Ma penso che il problema sia più che altro:"chi fa chi?" cioè, chi è che si dovrebbe occupare di spostare l'orologio? Ora non ho slackware sotto mano e i miei script di init sono tutti personalizzati, io so che il mio orologio non verrà spostato (sincronizzo in automatico l'orologio sempre con ntpd una volta connesso alla rete). Però se date uno sguardo agli script /etc/rc.d secondo me troviamo la risposta al problema.

Spina

Ho trovato questo che spiega tutto alla perfezione: http://www.pluto.it/files/ildp/HOWTO/Clock/Clock-2.html.

L'UTC non cambia al cambiare dell'ora legale-- quello che cambia è la conversione tra UTC e local time (l'orario locale). La traduzione in local time è operata da funzioni di libreria che vengono linkate nelle varie applicazioni.

Questo ha due conseguenze: primo, ogni applicazione che necessiti di conoscere il local time avrà anche bisogno di conoscere in che fuso orario ci si trovi, e se vige l'ora legale o meno (vedi la sezione successiva per maggiori dettagli sui fusi orari). Secondo, non c'è nessuna funzionalità nel kernel per cambiare l'orologio di sistema o l'RTC al variare dell'ora legale, perché l'UTC non cambia. Perciò i sistemi che funzionano solo con Linux dovrebbero avere l'RTC impostato sull'UTC, non sul local time.

[ZeroUno]

Il documento è un po' datato (parla del kernel 2.0.x), quindi spero siano cambiate un po' di cose, perchè sembrerebbe che in un sistema dualboot devo settare localtime e non ho speranza di modificare l'ora legale se non riavviando in windows (e se lo modifichi a mano avrai il problema, come sperimentato, che verrà rimodificata quando viene avviato windows). Mentre in un sistema non dualboot devo settare utc (al che non dovrei avere problemi).

Io ho un sistema trialboot


Ciao,
01

[Trotto@81]

Io ho schedulato il comando "ntpd -g -q" in crontab per essere eseguito ogni ora. All'avvio evito perchè voglio accorgermi se la batteria tampone perde colpi.
Oggi avvio la Slackware e lancio con da Konsole #ntpd -g -q per aggiustare l'ora, ma non succede nulla, il comando non mi restituisce niente e allo stesso tempo non torna al prompt dei comandi. Quello che mi fa impazzire è che se lo stesso comando viene lanciato da crontab nei log si vede chiaramente che il comando va a buon file.
Perchè questa strana distinzione?