Compilazione di C ++ su macchina Linux remota - avviso "clock skew rilevato"


168

Sono collegato al piccolo cluster Linux della mia università tramite PuTTY e WinSCP, trasferendo i file usando quest'ultimo e compilandoli ed eseguendoli con il primo. Finora il mio lavoro è stato svolto nei laboratori dell'università, ma oggi ho svolto alcuni lavori a casa che hanno generato un avvertimento interessante.

Ho caricato un'intera cartella di cose e, eseguendo il makecomando, ottengo questo come ultima riga di output:

make: attenzione: rilevata inclinazione dell'orologio. La tua build potrebbe essere incompleta.

Il binario risultante funziona correttamente e non sembrano esserci altri errori imprevisti nel processo di compilazione.

Mi sembra di essere in grado di innescare l'errore costruendo dopo aver caricato alcuni file nuovi / sostitutivi (modifico tutto localmente e poi carico la nuova versione), quindi mi chiedo se è qualcosa di altrettanto semplice dei tempi di modifica dei file non corrispondenti? O qualcosa di più preoccupante?

Quindi, dovrei essere preoccupato? Come posso risolvere / prevenire questo?


Le differenze di clock sono una possibilità, come indicato in alcune delle risposte. Puoi anche confrontare i tempi di modifica dei file sorgente prima e dopo la copia - potresti scoprire che sono un'ora diversa a causa dei due sistemi operativi / file system che trattano l'ora legale in modo diverso.
Steve Jessop,

Un ultimo suggerimento: non ho macchine Windows, quindi non ho familiarità con le funzionalità di PuTTY e WinSCP, ma spesso gli strumenti di trasferimento file hanno opzioni che ti consentono di controllare se il tempo modificato viene preservato o meno. I tempi dei tuoi mod sono ovviamente preservati, ma se riesci a spegnerli quando i file vengono copiati sul tuo sistema useranno i tempi dei mod impostati dal tuo orologio di sistema, non dall'orologio di sistema remoto.
MadScientist,

Risposte:


206

Quel messaggio di solito indica che alcuni dei tuoi file hanno tempi di modifica successivi all'ora di sistema corrente. Poiché makedecide quali file compilare quando si esegue una build incrementale controllando se un file di origine è stato modificato più di recente rispetto al suo file oggetto, questa situazione può causare la creazione di file non necessari o, peggio, i file necessari .

Tuttavia, se stai costruendo da zero (non eseguendo una build incrementale) puoi probabilmente ignorare questo avviso senza conseguenze.


4
Sembra che il cluster abbia un tempo di circa 3 minuti dietro il mio desktop, quindi i file che sono stati modificati in "futuro" sembrano una causa probabile. La scommessa più sicura è quindi aspettare circa 5 minuti dopo aver caricato qualcosa prima di eseguire una build? Preferirei non dover aspettare, quindi c'è un modo per resettare i tempi su qualsiasi file "futuro" caricato per evitare il problema?
DMA57361,

14
@ DMA57361: touch *aggiornerà i mtime all'ora corrente. In alternativa puoi abilitare NTP sul tuo desktop per sincronizzare il tuo orologio (supponendo che sia il tuo desktop che non va, e non la macchina di Uni ... se quest'ultima, forse chiedi agli amministratori di sistema di ripararlo?)
caf

2
Grazie per quello, touch *lo è per ora, e vedrò se riesco a scoprire quale è sbagliato e forse potrò parlare con il ragazzo dell'amministratore la prossima volta che sarò sul posto.
DMA57361

1
Avevo bisogno di un tocco ricorsiva nel mio caso:find . -exec touch {} \;
AMS

8
@AaronS per comandi come touchquello può accettare più file su cui agire, puoi farlo (molto) in modo più efficiente con il find . -exec touch {} +quale invocheremo il touchmaggior numero di argomenti possibile.
Viktor Dahl,

56

In genere ciò si verifica quando si crea in una directory montata NFS e gli orologi sul client e sul server NFS non sono sincronizzati.

La soluzione è eseguire un client NTP sia sul server NFS che su tutti i client.


1
Non sto costruendo su nessuna directory montata su NFS.
kingsmasher1,

Fammi sapere se puoi dare qualche consiglio per sopprimere tale avvertimento, in quanto non fa davvero alcuna differenza nell'esecuzione o nei risultati.
kingsmasher1,

@ kingsmasher1: esegue un client NTP su tutte le macchine coinvolte.
janneb,

Ho appena controllato il mio obiettivo. La data non è impostata. Non sono sicuro di come eseguire NTP qui. Va bene, se aggiorno la data? Il mio x86 su cui costruisco è impostato sulla data corrente, ma il mio target (dove eseguo) ha una data di soem degli anni '70.
kingsmasher1,

1
Il problema è stato risolto. Ho cambiato la mia data target con la data corrente e l'avvertimento è svanito. Quindi il problema è: se la data target è una data posteriore rispetto alla data eseguibile, il problema si verifica.
kingsmasher1,

22

Installa il Network Time Protocol

Questo è successo anche a me quando sono in esecuzione makesu una condivisione CIFS SMB Samba su un server. Una soluzione duratura consiste nell'installare il ntpdemone sia sul server che sul client. (Si noti che questo problema non viene risolto eseguendo ntpdate. Ciò risolverebbe la differenza di tempo solo temporaneamente, ma non in futuro.)

Per i sistemi derivati ​​da Ubuntu e Debian, digitare semplicemente la seguente riga nella riga di comando:

$ sudo apt install ntp

Inoltre, sarà ancora necessario emettere il comando touch *una volta (e solo una volta) nella directory interessata per correggere i tempi di modifica dei file una volta per tutte.

$ touch *

Per ulteriori informazioni sulle differenze tra ntpe ntpdate, consultare:



6

Secondo l' utente m9dhatter su LinuxQuestions.org :

"make" utilizza il timestamp del file per determinare se il file che sta tentando di compilare è vecchio o nuovo. se l'orologio è disallentato, potrebbe avere problemi durante la compilazione.

se si tenta di modificare i file su un'altra macchina con un tempo di anticipo di alcuni minuti e trasferirli sulla propria macchina e quindi provare a compilare, si potrebbe avvertire un avviso che dice che il file è stato modificato dal futuro. l'orologio potrebbe essere distorto o qualcosa del genere (non ricordo davvero). potresti semplicemente ls nel file offensivo e fare questo:

#touch <nome file del file offensivo>


6

Le altre risposte qui fanno un buon lavoro nel spiegare il problema, quindi non lo ripeterò qui. Ma esiste una soluzione che può risolverla che non è ancora elencata: esegui semplicemente make clean, quindi esegui nuovamente make.

Avere fatto rimuovere qualsiasi file già compilato impedirà a make di avere qualsiasi file per confrontare i timestamp di, risolvendo l'avviso.


questa non è una vera soluzione: se il compilatore ha bisogno di 30 minuti per compilare tutto e sto lavorando su un singolo file (dove la build richiede solo 2 secondi), sprecherò tutto il giorno per apportare modifiche su una singola parte di un enorme biblioteca. Destra? Tuttavia sì, con make cleante risolverai i problemi (creando altri).
Leos313

@ Leos313 Sto solo condividendo ciò che ha funzionato per me. L'ho trovato su una rete scolastica su cui non avevo i permessi di root, quindi non potevo configurare NTP e non mi fidavo dei risultati della compilazione del solo utilizzo touchsu tutti i file. Hai ragione che richiederà una completa ricompilazione, ma se valga la pena o meno che il tempo varierà a seconda delle priorità e delle dimensioni del progetto. Non credo sia corretto affermare che "non è una vera soluzione" solo perché non è la migliore o presenta alcuni inconvenienti. Risolverà il problema; sembra una soluzione per me.
skrrgwasme,

Non ho votato verso il basso :) risolve il problema creando altri. Nient'altro che questo! :) di sicuro la risposta aiuterà nella maggior parte della situazione e vale la pena essere qui! Quello che voglio sottolineare e, a volte, è meglio stare con l'avvertimento piuttosto che correremake clean
Leos313

4

Ho avuto questo in passato - a causa degli orologi che erano fuori sulle macchine. Prendi in considerazione la configurazione di NTP in modo che tutte le macchine abbiano lo stesso tempo.


2

Questo di solito è semplicemente dovuto a tempi di mancata corrispondenza tra i computer host e client. Puoi provare a sincronizzare i tempi sui tuoi computer usando ntp .


1

La soluzione è eseguire un client NTP, basta eseguire il comando come di seguito

#ntpdate 172.16.12.100

172.16.12.100 è il server ntp


2
Benvenuto in Stack Overflow! Grazie per il tuo post! Non utilizzare firme / slogan nei tuoi post. La casella utente conta come firma e puoi utilizzare il tuo profilo per pubblicare qualsiasi informazione su di te che ti piace. FAQ su firme / slogan
Andrew Barber,

L'utilizzo ntpdateè solo una correzione una tantum. È meglio installare ntpsia sul server che sul client per ottenere una soluzione duratura.
Serge Stroobandt,

1

Sostituisci la batteria dell'orologio nel tuo computer. Ho visto questo messaggio di errore quando la batteria a forma di moneta sulla scheda madre aveva bisogno di essere sostituita.


1

(Nel caso in cui qualcuno arrivi qui) Se si dispone dei diritti sudo, un'opzione è sincronizzare l'ora di sistema

sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"

-1

Verifica se il risultato della compilazione, ad esempio somefile.o, è più vecchio della fonte, ad esempio somefile.c. L'avvertimento sopra indica che qualcosa sui timestap dei file è strano. Probabilmente gli orologi di sistema del server dell'Università differiscono dal tuo orologio e, ad esempio, si invia alle 13:00 un file con data di modifica alle 14:00. Puoi vedere l'ora sulla console digitando la data.


-3

Questo mi è successo. È perché ho corso make -j 4e alcuni lavori sono finiti fuori servizio. Questo avviso dovrebbe essere previsto quando si utilizza l' -jopzione di.


5
I lavori finiti fuori servizio sono ok. Non significa che il tempo di modifica dovrebbe essere in futuro.
klimkin,

@klimkin Perché no? Penso che alcuni processori abbiano finito di costruire componenti prima dell'avvio di altri processori.
kilojoules,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.