ይህ ቀላል ስራ አንድ አርብ ከሰአት በኋላ ተነስቷል እና ከ2-3 ደቂቃዎችን መውሰድ ነበረበት። በአጠቃላይ, እንደ ሁልጊዜ.
አንድ የሥራ ባልደረባዬ ስክሪፕቱን በአገልጋዩ ላይ እንዳስተካክለው ጠየቀኝ። አደረግሁት፣ ለእሱ ሰጠሁት እና ሳላስበው ጣልኩት፡ “ጊዜው 5 ደቂቃ ፈጣን ነው።” አገልጋዩ ማመሳሰልን በራሱ እንዲይዝ ያድርጉ። ግማሽ ሰአት አንድ ሰአት አለፈ እና አሁንም እየነፈሰ በጸጥታ ተሳደበ።
“ደደብ! - ወደ አገልጋይ ኮንሶል በመቀየር ላይ አሰብኩ - እሺ፣ ለሁለት ተጨማሪ ደቂቃዎች እረፍት እወስዳለሁ።
እስኪ እናያለን ntp፣ rdate፣ sdwdate አልተጫነም በጊዜ የተመሳሰለ የአካል ጉዳተኛ እና የማይሰራ.
# timedatectl
Local time: Sun 2019-08-25 20:44:39 +03
Universal time: Sun 2019-08-25 17:44:39 UTC
RTC time: Sun 2019-08-25 17:39:52
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: no
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
እዚህ ወዲያውኑ የሃርድዌር ጊዜ ትክክል መሆኑን አስተውያለሁ: የበለጠ ለማሰስ ቀላል ይሆናል.
ተከታታይ ስህተቶች የጀመሩት እዚህ ነው።
የመጀመሪያው ስህተት. በራስ መተማመን
ክሊክ - ክሊክ ...
# systemctl enable systemd-timesyncd.service && systemctl start systemd-timesyncd.service && ntpdate 0.ru.pool.ntp.org && timedatectl set-ntp on && timedatectl
25 Aug 21:00:10 ntpdate[28114]: adjust time server 195.210.189.106 offset -249.015251 sec
Local time: Sun 2019-08-25 21:00:10 +03
Universal time: Sun 2019-08-25 18:00:10 UTC
RTC time: Sun 2019-08-25 18:00:10
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: n/a
ሁሉም ነገር ጥሩ ነው, ጊዜው ተመሳስሏል, የስርዓቱ ጊዜ ከሃርድዌር ጋር ይዛመዳል. “ውሰደው” አልኩና ወደ ንግዴ ተመለስኩ።
“ምን ውሰድ? - ባልደረባው ተናደደ። "አንድ ጊዜ ነው!"
የተለመዱ ችግሮችን በፈታህ መጠን፣ አስተሳሰብህ እየደበዘዘ ይሄዳል እናም መቶኛው ወይም ሺህኛው ሁኔታ የተለየ ይሆናል ብለው አያስቡም ፣ ግን በዚህ ጊዜ አይደለም።
# timedatectl
Local time: Sun 2019-08-25 21:09:15 +03
Universal time: Sun 2019-08-25 18:09:15 UTC
RTC time: Sun 2019-08-25 18:05:04
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
የስርዓቱ ጊዜ እንደገና የተሳሳተ ነው።
እንደገና እንሞክር፡-
# ntpdate 0.ru.pool.ntp.org && timedatectl && sleep 1 && timedatectl
25 Aug 21:07:37 ntpdate[30350]: step time server 89.175.20.7 offset -249.220828 sec
Local time: Sun 2019-08-25 21:07:37 +03
Universal time: Sun 2019-08-25 18:07:37 UTC
RTC time: Sun 2019-08-25 18:07:37
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: n/a
Local time: Sun 2019-08-25 21:11:46 +03
Universal time: Sun 2019-08-25 18:11:46 UTC
RTC time: Sun 2019-08-25 18:07:37
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
በተለየ መንገድ እናድርገው፡-
# date -s "2019-08-25 21:10:30" && date && sleep 1 && timedatectl
Sun Aug 25 21:10:30 +03 2019
Sun Aug 25 21:10:30 +03 2019
Local time: Sun 2019-08-25 21:14:36 +03
Universal time: Sun 2019-08-25 18:14:36 UTC
RTC time: Sun 2019-08-25 18:10:30
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
እና እንደዚህ፡-
# hwclock --hctosys && timedatectl && sleep 1 && timedatectl
Local time: Sun 2019-08-25 21:11:31 +03
Universal time: Sun 2019-08-25 18:11:31 UTC
RTC time: Sun 2019-08-25 18:11:31
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: n/a
Local time: Sun 2019-08-25 21:15:36 +03
Universal time: Sun 2019-08-25 18:15:36 UTC
RTC time: Sun 2019-08-25 18:11:32
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
ሰዓቱ ለአንድ ሰከንድ ተዘጋጅቷል, እና ወዲያውኑ እንደገና "መቸኮል" ይጀምራል.
በተመሳሳይ ጊዜ, በምዝግብ ማስታወሻዎች ውስጥ, እንደዚህ አይነት በእጅ በሚቀየርበት ጊዜ, የስርዓት ሪፖርቶችን ብቻ እናያለን, ጊዜው እንደተለወጠ, በቅደም ተከተል, በትክክለኛው / የተሳሳተ አቅጣጫ እና አልፎ አልፎ. እንደገና በማመሳሰል ላይ ከሥርዓት-timesyncd.
Aug 25 21:18:51 wisi systemd[1]: Time has been changed
Aug 25 21:18:51 wisi systemd-timesyncd[29258]: System time changed. Resyncing.
Aug 25 21:18:51 wisi systemd[1187]: Time has been changed
Aug 25 21:18:51 wisi systemd[1]: Time has been changed
Aug 25 21:18:51 wisi systemd[1187]: Time has been changed
እዚህ
# ps afx | grep "[1]187"
1187 ? Ss 0:02 /lib/systemd/systemd --user
በዚህ ጊዜ, ምክንያቱን መፈለግ ቀድሞውኑ አስፈላጊ ነበር, ነገር ግን ከ 18 ዓመታት በላይ አስተዳደር, አንጎል በ "ጊዜ" ስህተቶች ላይ ስታቲስቲክስን አከማችቷል እና ከልምዱ, እንደገና ማመሳሰልን ተጠያቂ ያደርጋል.
ሙሉ በሙሉ እናጥፋው።
# timedatectl set-ntp off && systemctl stop systemd-timesyncd.service
# hwclock --hctosys && timedatectl && sleep 1 && timedatectl
Local time: Sun 2019-08-25 21:25:40 +03
Universal time: Sun 2019-08-25 18:25:40 UTC
RTC time: Sun 2019-08-25 18:25:40
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: no
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
Local time: Sun 2019-08-25 21:29:31 +03
Universal time: Sun 2019-08-25 18:29:31 UTC
RTC time: Sun 2019-08-25 18:25:41
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: no
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
እና በምዝግብ ማስታወሻዎች ውስጥ
Aug 25 21:25:40 wisi systemd[1]: Time has been changed
Aug 25 21:25:40 wisi systemd[1187]: Time has been changed
Aug 25 21:29:30 wisi systemd[1]: Time has been changed
Aug 25 21:29:30 wisi systemd[1187]: Time has been changed
እንደገና በማመሳሰል ላይ ጠፍተዋል እና አለበለዚያ ግንዶች ንጹህ ናቸው.
መደምደሚያዎችን በማጣራት ላይ tcpdump በሁሉም መገናኛዎች ላይ ወደብ 123. ምንም ጥያቄዎች የሉም፣ ግን ጊዜው አሁንም እየሮጠ ነው።
ስህተት ሁለት። መቸኮል
የስራው ሳምንት ሊጠናቀቅ አንድ ሰአት ቀርቷል፣ እና ቅዳሜና እሁድን በትናንሽ ያልተፈታ ችግር መሄድ አልፈልግም (በኮዱ ውስጥ ላለው ጊዜ ትኩረት አትስጥ፣ ጽሑፉ በቀጣዮቹ ቀናት ውስጥ ተጽፏል) ).
እና እዚህ እንደገና ምክንያቱን ከመፈለግ ይልቅ ለውጤቱ ማብራሪያ ለመስጠት መሞከር ጀመርኩ. “ፈጠራ” እላለሁ ምክንያቱም ለውጤቱ የሚሰጠው ማብራሪያ ምንም ያህል ምክንያታዊ ቢሆንም ችግሩን ለመፍታት የተሳሳተ አካሄድ ነው።
ይህ አገልጋይ የዥረት አገልጋይ ነው እና የDVB-S2 ዥረት ወደ አይፒ ይቀይራል። የDVB-S ዥረት የጊዜ ማህተሞችን ይዟል፣ስለዚህ ተቀባዮች፣ multiplexers፣ scramblers እና ቴሌቪዥኖች የስርዓት ሰዓቱን ለማመሳሰል ብዙ ጊዜ ይጠቀማሉ። የDVB-S ቦርድ ሾፌሮች በከርነል ውስጥ የተገነቡ ናቸው, ስለዚህ የ DVB-S2 ዥረት መወገዱን ለማረጋገጥ ፈጣኑ መንገድ ከ "ፕላቶች" የሚመጡትን ገመዶች ማለያየት ነው. እንደ እድል ሆኖ, አገልጋዩ ከግድግዳው በስተጀርባ ነው, ስለዚህ ይሁን.
በእርግጥ, ምዝግብ ማስታወሻዎቹ እዚያ መሆን ያለባቸውን ነገሮች ቢይዙ, ይህ አይከሰትም ነበር, ነገር ግን የበለጠ በዚያ ላይ, በድጋሚ, በአንቀጹ መጨረሻ ላይ.
ደህና ፣ ሁሉንም የሳተላይት ምልክቶችን ስላስወገድን ፣ ምድራዊ የሆኑትንም እናስወግዳለን - በተመሳሳይ ጊዜ ሁሉንም የአውታረ መረብ ገመዶች እናወጣለን። አገልጋዩ ከውጭው ዓለም ተቆርጦ ሙሉ በሙሉ በራስ ገዝ ይሠራል፣ ነገር ግን የስርዓት ሰዓቱ አሁንም በችኮላ ላይ ነው።
የስራ ሳምንት አልቋል፣ እና የቀን/ሰአት ጉዳይ ራሱ ወሳኝ አይደለም፣ ስለዚህ ወደ ቤት ብቻ መሄድ ትችላላችሁ፣ ግን እዚህ አዲስ ስህተት እሰራለሁ።
ስህተት ሶስት. አማካሪዎች
በጭራሽ! ለሱ መልሱ የጎግልን የመጀመሪያ ገጽ ከማጥናት እና የአንድ ሰው ገጽ ከማንበብ የበለጠ የሚፈልግ ከሆነ በፎረሞች እና በአጠቃላይ ልዩ (a la stackoverflow) ጣቢያዎች ላይ ጥያቄዎችን በጭራሽ አይጠይቁ።
ወደ ጎግል መልሰው ይልክልዎታል ፣ ተመሳሳዩን ሰው ያንብቡ እና የፎረሙን / የጣቢያውን ህጎች በሰፊው ያብራራሉ ፣ ግን መልስ አይሰጡዎትም።
አንዳንድ ተጨባጭ ምክንያቶች እዚህ አሉ
- ችግሩን ከአንተ በስተቀር ማንም ሊያውቅ አይችልም;
- እንደ እርስዎ ባሉ ሁኔታዎች ማንም ሰው ፈተናዎችን ማካሄድ አይችልም።
እና ተጨባጭ፡-
- ችግሩን ለመፍታት ሁሉንም ግብዓቶች ላይሰጡ ይችላሉ ፣ ምክንያቱም ቀድሞውኑ “ትክክለኛውን” አቅጣጫ ይዘው ስለመጡ እና የጉዳዩን ይዘት በእሱ ላይ ያተኮሩ ናቸው ።
- ፎርማን (አወያይ፣ ሽማግሌ፣ አስተዳዳሪ) ሁል ጊዜ ትክክል ነው፣ ፎርማን ከተሳሳተ... ደህና፣ ታውቃለህ...
ለአስተያየቶች ምላሽ በሚሰጡበት ጊዜ ሳንሱር በተደረጉ መዝገበ-ቃላት ገደብ ውስጥ ከቆዩ ጠንካራ ነርቮች አለዎት።
ዉሳኔ
ስራዎችን ወደ ቀላል እና ውስብስብ መከፋፈል አያስፈልግም.
በእኛ ልምድ, ስታቲስቲክስ, አማካሪዎች ላይ መታመንን እናቆማለን እና የመጨረሻውን ውጤት "ማብራራት" ሳይሆን ምክንያቱን በተከታታይ መፈለግ እንጀምራለን.
አንድ ሰው ሰዓቱን ስለሚወስን ተጓዳኝ የስርዓት ጥሪ መከሰት አለበት።
በሶፍትዌር ሰነዶች ውስጥ ምርጥ ሰነዶች ምንጮች እንደሆኑ ሁሉ በስርዓት አስተዳደር ውስጥ በጣም ጥሩው ረዳት ኦዲት ነው, በእኛ ሁኔታ ኦዲት ተደርጓል.
የጥርጣሬ አፍታበማና ውስጥ ሄጄ ነበር, ነገር ግን በሊኑክስ ውስጥ ያለው ጊዜ ብቻ ሊዘጋጅ እንደሚችል ሙሉ በሙሉ እርግጠኛ አልነበርኩም የሰዓት_ሰዓት и የቀኑን ሰዓትስለዚህ ለመጀመሪያው ሙከራ ሁሉንም "ተስማሚ" ጥሪዎች መርጫለሁ-
# man syscalls | col | grep -F '(2)' | grep -vE '(:|;)' | grep -E '(time|date|clock)' | sed "s/(2).*//" | xargs -I SYSCALL echo "-S SYSCALL " | xargs echo
-S adjtimex -S clock_adjtime -S clock_getres -S clock_gettime -S clock_nanosleep -S clock_settime -S futimesat -S getitimer -S gettimeofday -S mq_timedreceive -S mq_timedsend -S rt_sigtimedwait -S s390_runtime_instr -S setitimer -S settimeofday -S stime -S time -S timer_create -S timer_delete -S timer_getoverrun -S timer_gettime -S timer_settime -S timerfd_create -S timerfd_gettime -S timerfd_settime -S times -S utime -S utimensat -S utimes
እና መጣል s390_runtime_instr፣ stime፣ timerfd_create፣ የትኛው ኦዲትትኤል አላውቀውም ነበር፣ መጀመሪያ ላይ ኦዲት በፎርም ጀመረ፡-
auditctl -a exit,always -S adjtimex -S clock_adjtime -S clock_getres -S clock_nanosleep -S clock_settime -S futimesat -S getitimer -S gettimeofday -S mq_timedreceive -S mq_timedsend -S rt_sigtimedwait -S semtimedop -S setitimer -S settimeofday -S time -S timer_create -S timer_delete -S timer_getoverrun -S timer_gettime -S timer_settime -S timerfd_gettime -S timerfd_settime -S times -S utime -S utimensat -S utimesየምፈልጋቸው የምዝግብ ማስታወሻዎች ውስጥ ሌላ ምንም ምዝግብ ማስታወሻ አለመኖሩን ካረጋገጥኩ በኋላ ሲስካሎች ከእነዚህ ከሁለቱ በተጨማሪ እነሱን ብቻ ነው የተጠቀምኳቸው።
የስርዓት ጥሪ ኦዲት በማካሄድ ላይ የሰዓት_ሰዓት и የቀኑን ሰዓት እና ቀኑን ለመለወጥ ይሞክሩ:
# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D
የእኛ "ፓራሳይት" ሰዓቱን ለማረም ዋስትና እንዲሰጥ አምስት ሰከንድ መዘግየት ተጨምሯል.
ዘገባውን እንመልከት፡-
# aureport -s -i
Syscall Report
=======================================
# date time syscall pid comm auid event
=======================================
Warning - freq is non-zero and incremental flushing not selected.
1. 08/22/2019 12:10:00 settimeofday 3088 chkcache_proces root 479630
2. 08/26/2019 09:37:06 clock_settime 1538 date root 479629
እዚህ የእኛን እናያለን ቀን እና ለእኛ የማይታወቅ chkcache_ሂደቶች. ከላይ ባለው ዘገባ ላይ አብቅቷል ምክንያቱም አውሬፖርት ከሁለትዮሽ ሲቀየር ውጤቱን በቀን ስለደረደረ እና ክስተቱ የተከሰተው እኛ ባዘጋጀንበት ጊዜ ነው። ቀን -ሰ "2019-08-22 12:10:00".
ማን ወለደው?
# ausearch -sc settimeofday --comm "chkcache_proces"
----
time->Thu Aug 22 12:10:00 2019
type=PROCTITLE msg=audit(1566465000.000:479630): proctitle="/usr/local/bin/oscam"
type=SYSCALL msg=audit(1566465000.000:479630): arch=c000003e syscall=164 success=yes exit=0 a0=7fde0dfc6e60 a1=0 a2=136cf a3=713ba56 items=0 ppid=3081 pid=3088 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts20 ses=68149 comm="chkcache_proces" exe="/usr/local/bin/oscam" key=(null)
/usr/local/bin/oscam - የእኛ ጥገኛ ተገኝቷል. ምንም እንኳን "ተንኮል አዘል" ባህሪው ቢሆንም, ሁኔታዊ የመዳረሻ ስርዓቱን አለመቀበል አይቻልም, ግን አሁንም ማወቅ እፈልጋለሁ. oscam፣ WTF?
መልሱ በፍጥነት ውስጥ ይገኛል :
#if defined(CLOCKFIX)
if (tv.tv_sec > lasttime.tv_sec || (tv.tv_sec == lasttime.tv_sec && tv.tv_usec >= lasttime.tv_usec)) // check for time issues!
{
lasttime = tv; // register this valid time
}
else
{
tv = lasttime;
settimeofday(&tv, NULL); // set time back to last known valid time
//fprintf(stderr, "*** WARNING: BAD TIME AFFECTING WHOLE OSCAM ECM HANDLING, SYSTEMTIME SET TO LAST KNOWN VALID TIME **** n");
}
እዚህ እንዴት የሚያምር ይመስላል የሚል አስተያየት ሰጥቷል መስመር ማስጠንቀቂያ...
ምንጭ: hab.com