Clock Skew's und andere Missgeschicke

Kollege

Kollege

tiefer vogel
Hatte die letzten Tage immer das Problem, dass meine BIOS-Uhr nach jedem Reboot falsch ging. Wo das Problem lag, wurde mir auch später nicht wirklich klar.

Auch das hier hat leider nichts gebracht, wäre sowieso unwahrscheinlich gewesen, denn die Uhr verstellte sich auch ohne Windows-Boot:
Code:
nano /etc/conf.d/clock
# Set CLOCK to "UTC" if your system clock is set to UTC (also known as
# Greenwich Mean Time).  If your clock is set to the local time, then
# set CLOCK to "local".  Note that if you dual boot with Windows, then
# you should set it to "local".

CLOCK="UTC"

Dieser Eintrag in der gleichen Datei, hat dann meine Probleme gelöst, worüber ich sehr froh war:
Code:
# If you want to set the Hardware Clock to the current System Time
# during shutdown, then say "yes" here.

CLOCK_SYSTOHC="yes"

Sehr ärgerlich ist es, wenn man zur falschen Uhrzeit, dann sein System ganz neu baut... (emerge --sync && emerge -avDuN world) Dann merkt man, dass man eine wichtige C-Flag vergessen hat und den ganzen Prozess mit der (diesmal) richtigen Uhrzeit wiederholen muss............

CLOCK SKEW, SCHLEIFEN, und noch mal CLOCK SKEW

(bitte vorher 'su' und 'cd /' sonst fürn A****)
Code:
the_grim_reaper / # find -mtime -0 > verdammt
the_grim_reaper / # du -h verdammt 
6.8M    verdammt

Da weiss man doch, was man vermeiden sollte...:D

Nun dachte Ich alle meine Probleme lösen sich mit dieser wunderbaren Zeile in Luft auf:
Code:
touch $(find -mtime -0) &> /dev/null

Aber nein:
Code:
bash: /usr/bin/touch: Argument list too long

Unter http://www.linuxjournal.com/article/6060 werden dazu einige Lösungen genannt. Ich wollte dann die 'brutale' Methode 4 anwenden (ich stehe eben auf Holzhämmer), als mir beim Ausführen dann eine Frage kam: wenn meine Dateiliste 6.8Mb gross ist, auf welchen Wert, dann MAX_ARG_PAGES setzen? Plötzlich kam mir der Holzhammer gar zu brutal vor, und ich habe die Kommentare unter dem Artikel gelesen.

Code:
find -mtime -0  | xargs touch

womit mein Problem dann erstmal gelöst war, und mein rebuild bisher ganz artig läuft. Der Pipe sei gedankt. Klar, es ist eine abartig unsaubere Lösung, denn man durchsucht und modifiziert damit auch /dev, /sys und /proc, aber das habe dann einfach in Kauf genommen.

Ich hoffe, dass wenn jemand genauso ungeschickt war wie ich, demjenigen damit geholfen zu haben ;)

mfg kollege

ps: Ich wette einer unserer Gurus trumpft jetzt mit seinem 'schmutzigen PERL-hack' auf :devil:
 
Ach Perl-Hack, iwo. Deine Lösung ist doch gerade ein gutes Beispiel dafür warum wir unsere Linux Systeme so mögen, weil die Shell so stark ist und vieles einfach zu lösen ist. Xargs ist übrigens ein saugeniales Tool, das du dir auf jeden Fall merken solltest. Ein Tip noch:
Die Optionen find -print0 und xargs -0 sollten verwendet werden, das erspart dir Probleme mit Leerzeichen in Dateinamen.

Ansonsten ist die find / xargs Kombi etwas was ich selbst sehr häufig benutze. Aber:
man find solte den Parameter -exec hervorbringen, der ermöglicht das sogar ohne xargs...

Just my 2 cents
 

Ähnliche Themen

Nginx als Reverse Proxy für Nextcloud und Emby

Zugriff Ubuntu 16.04. auf Freigabe 18.04. LTS nicht möglich

OpenJDK8 unter Debian7.11/sparc64/kernel 3.16 kompilieren

X startet nichtmehr

Samba 4 Gast Zugang unter Ubuntu funktioniert nicht

Zurück
Oben