ntpdate এবং ntpd লিনাক্সে ঘড়ি সিঙ্ক করতে ব্যর্থ

আমার এক সার্ভার নিয়ে আমার একটি অদ্ভুত সমস্যা রয়েছে। ntpdএবং ntpdateকাজ করতে ব্যর্থ, কিন্তু ডিবাগিং এ কোনও ত্রুটি দেখায় না। প্রথমে আমি ভেবেছিলাম সম্ভবত কোনও স্থানীয় বা নেটওয়ার্ক ফায়ারওয়াল ইউডিপি পোর্ট 123 টি ব্লক করছে, তবে এটি নয় - এই সার্ভারটি ইউডিপি পোর্ট 123 (এনটিপি প্রোটোকল) ইন্টারনেটে কথা বলতে এবং উত্তর পেতে পারে।

আমি ইস্যুটি প্রদর্শন করি

date -s "30 DEC 2012 02:30:00" - কাজ করে, তাই আমি ত্রুটি ছাড়াই সফলভাবে ঘড়িটি সেট করতে পারি।

ntpq -pn pool.ntp.org - কাজ করে, আমি টাইমসারভার থেকে বিশদ সময় ডেটা পাই এবং ইউডিপি প্যাকেটগুলি কাজ করছে তা প্রমাণ করে।

ntpdate -d pool.ntp.org - ডিবাগ মোড কাজ করে, এক টন ডিবাগ ডেটা দেখায় এবং বর্তমান সময়ের অফসেট দেখায়: 30 Dec 02:38:56 ntpdate[19267]: step time server 208.97.140.69 offset 228.234554 sec

সমস্ত স্বাভাবিক দেখা যাচ্ছে, অবধি: ntpdate pool.ntp.org- ৪.7 সেকেন্ড বিরতি দেওয়ার পরে, এটি ফিরে আসে: 30 Dec 02:41:29 ntpdate[19274]: no server suitable for synchronization found

একই সমস্যা চলমান ntpd, এটি ঘড়িটি আপডেট করে না।

ntpq -pnএনটিপিডি শুরু হওয়ার পরে, সমস্ত রিফিডের ফলাফল চিরকালের জন্য আটকে যায় .INIT.যার অর্থ তারা সিঙ্ক করতে পারে না।

/ var / lib / ntp / ড্রিফ্টটি হল ntp.conf এ ড্রিফ্টফিল সেটিংস, যা chmod 644 এবং এনটিপি: এনটিপি-র মালিকানা, আমার অন্যান্য সমস্ত সিস্টেমের মতো।

আমি আরও কয়েক ডজন এনটিপি সময় সার্ভার চেষ্টা করেছি, iptables ফায়ারওয়াল অক্ষম করেছি এবং নিশ্চিত করেছি যে ডেটাসেন্টার ইউডিপি ট্র্যাফিক ফিল্টার করছে না। আমার ক্লকটি সিঙ্ক করা থেকে এনটিপিডি এবং এনটিপিডেটে কি থামছে এমন কোনও ধারণা?

এটি CentOS 6.3 x64 ইন্টেল সিপিইউ সহ একটি ডেডিকেটেড সার্ভারে।

ntp ntpd ntpdate

— ক্র্যাশ ওভাররাইড
সূত্র

আপনি "ডেডিকেটেড সার্ভার" বলতে কী বোঝাতে চান তা কি স্পষ্ট করে বলতে পারেন - এটি কি শারীরিক হার্ডওয়্যার, বা ভার্চুয়াল মেশিন?

— শেন ম্যাডেন

উত্সর্গীকৃত সার্ভার = শারীরিক হার্ডওয়্যার। ভার্চুয়াল মেশিন নয়।

— ক্র্যাশ ওভাররাইড

উত্তর:

ntpdate(এবং ntpd) অফসেটটি বেশি বেশি হলে (সহজেই) সময় সেট করতে অস্বীকার করবে। উভয় অ্যাপ্লিকেশন ধীরে ধীরে আপনার সময়কে সামঞ্জস্য করার চেষ্টা করবে , যাতে আপনার সিস্টেমকে বিভ্রান্ত না করে এবং এমন কোনও অ্যাপ্লিকেশন যা বড় সময়ের ঝাঁপটিকে খুব ভালভাবে পরিচালনা করতে পারে না।

ntpdate -bপরিবর্তে চেষ্টা করুন। এটি যতই অযৌক্তিক মনে হোক না কেন সময় নির্ধারণ করবে।

আপনার -uপতাকাও যুক্ত করতে হবে যা ntpdateসুবিধাযুক্ত (<1024) পোর্টগুলি ব্যবহার করা থেকে বিরত থাকবে । নোট যে -uদ্বারা নিহিত -d! এবং মনে হচ্ছে এটি ঠিকঠাক -dকাজ করছে।

যদি যোগ করা যদি -uকাজ করা এবং অ-কর্মহীনতার মধ্যে পার্থক্য তৈরি করে, তবে আপনার এই পথে যে ফায়ারওয়াল রয়েছে তা এই সমস্যাগুলি সৃষ্টি করছে।

এবং দুর্ভাগ্যক্রমে একটি সীমাহীন বন্দর ব্যবহার করা সম্ভব হবে বলে মনে হয় নাntpd ।

— chutz
সূত্র

তবুও ব্যর্থ। ntpdate -b pool.ntp.orgফলাফল: 30 Dec 03:00:10 ntpdate[1341]: no server suitable for synchronization foundএনটিপিডিট ডিবাগ পতাকাটি যা -dডিবাগ ডেটা দেখায় তবে বাস্তবে সিঙ্ক হয় না এবং এটি কাজ করে: ntpdate -d pool.ntp.orgফলাফল:30 Dec 03:00:55 ntpdate[1343]: step time server 128.10.254.6 offset 228.030338 sec

— ক্র্যাশ ওভাররাইড

@ ক্র্যাশ ওভারাইড, আমি উত্তরটি আপডেট করেছি কারণ ব্যাখ্যা করার চেষ্টা করার জন্য কেন -dঅন্যথায় এটি কাজ করছে না।

— chutz

ntpdate -b -uকাজ !!! অসাধারণ. দুটি প্রশ্ন। এনটিপিডি ডিমন এখনও ব্যর্থ হচ্ছে, সুবিধাজনক বন্দরগুলি ব্যবহার না করার জন্য আমি কীভাবে এটি পাব? দ্বিতীয় প্রশ্ন, আমার সমস্ত অন্যান্য সার্ভার যখন না করে এই মেশিনটি সুবিধামুক্ত বন্দরগুলিতে এনটিপি দিয়ে ব্যর্থ হয় কেন?

— ক্রাশ ওভাররাইড

হুম, আমার সার্ভার থেকে ফায়ারওয়াল ব্লক করার উত্স ইউডিপি পোর্ট 123 থাকতে পারে। যাচাই করা হচ্ছে। আবার, আপনার উত্তরের জন্য ধন্যবাদ।

— ক্রশ ওভাররাইড

এনটিপিডি উত্স বন্দর পরিবর্তন করা সম্ভব নয় তা বোঝাতে আমি একটি লিঙ্ক দিয়ে আপডেট করেছি। দুঃখিত, আমি এই লিঙ্কটি সন্ধানের চেয়ে আর তাকিয়ে দেখিনি।

— চটজ

আপনি পেস্টবিনে নিম্নলিখিত ফলাফলগুলি সরবরাহ করতে পারেন?

cat /etc/ntp.conf
cat /etc/sysconfig/ntpd
ntpq -pn
ntpdc -c sysstat
ntpdc -c kerninfo
ntpdc -c loopinfo
ntpdate -d <time-server-IP>
ntptrace

আপনি স্ট্র্যাটাম 1 সার্ভার বা অন্য যে কোনও কিছু থেকে সিঙ্ক করছেন।

সিঙ্ক্রোনাইজেশনের জন্য উপযুক্ত কোনও সার্ভারের অর্থ এটি যা বলে, তা ক্লায়েন্ট এবং সার্ভারের মধ্যে যোগাযোগ স্থাপন করা যায় না।

আমরা যদি ডেটার এই সেট থেকে কোনও সূত্র খুঁজে না পাই, প্যাকেটটি কোথায় হারিয়ে যাচ্ছে তা দেখার জন্য tcpdump প্রয়োজন হতে পারে।

tcpdump -s0 -i ethX -p udp -w /tmp/ntp.pcap

থামুন এবং এনটিপিডি ডিমন শুরু করুন এবং 377 এ যাওয়ার জন্য অপেক্ষা করুন এবং তারপরে tcpdump বন্ধ করুন। এটি আরও ক্লু দেওয়া উচিত।

— সোহম চক্রবর্তী
সূত্র

পেস্টবিন.com

— ক্র্যাশ ওভাররাইড