എന്തുകൊണ്ടാണ് Adminer.php ശൂന്യമായിരിക്കുന്നത്? പേരുമാറ്റുന്നത് നന്നായി പ്രവർത്തിക്കുന്നുണ്ടോ? കാരണത്തിന്റെ വിശകലനവും 3-ഘട്ട പരിഹാരവും.

ഇന്നലെ ഉച്ചകഴിഞ്ഞ്, ഞാൻ സെർവറിൽ അഡ്മിനർ ഡാറ്റാബേസ് മാനേജ്മെന്റ് ടൂൾ കോൺഫിഗർ ചെയ്യുകയായിരുന്നു. അഡ്മിനർ ഭാരം കുറഞ്ഞതും ഉപയോഗിക്കാൻ എളുപ്പവുമാണ്; ഒരു കൂട്ടം ഡിപൻഡൻസികൾ ആവശ്യമുള്ള phpMyAdmin-ൽ നിന്ന് വ്യത്യസ്തമായി, ഒരൊറ്റ PHP ഫയൽ ആ ജോലി ചെയ്യുന്നു . ഞാൻ ഔദ്യോഗിക വെബ്‌സൈറ്റിൽ നിന്ന് ഏറ്റവും പുതിയ പതിപ്പ് ഡൗൺലോഡ് ചെയ്‌ത്, സെർവറിലേക്ക് അപ്‌ലോഡ് ചെയ്‌ത്, അനുമതികൾ സജ്ജമാക്കി, എന്റെ ബ്രൗസർ തുറന്നു, അത് പരിശോധിക്കാൻ തയ്യാറായി.

പിന്നെ, എല്ലാം ശൂന്യമായി.

ഞാൻ പേജ് മൂന്ന് തവണ പുതുക്കി, F5 പലതവണ അമർത്തി വിരലുകൾ വേദനിച്ചു. എന്നിട്ടും ഒന്നുമില്ല. ഞാൻ ബ്രൗസറിന്റെ ഡെവലപ്പർ ടൂളുകൾ തുറന്നു; അത് 200 OK പിശക് കാണിച്ചു, പക്ഷേ പ്രതികരണ ബോഡി ശൂന്യമായിരുന്നു. ഞാൻ പൂർണ്ണമായും സ്തബ്ധനായി. എന്താണ് സംഭവിക്കുന്നത്?

ഒരു നിമിഷം ഞാൻ ആലോചിച്ചു. ഫയൽ പെർമിഷൻ പ്രശ്നമായിരിക്കുമോ? ഞാൻ പരിശോധിച്ചു, 755 ആയിരുന്നു. പിഎച്ച്പി പതിപ്പിന്റെ പൊരുത്തക്കേടായിരിക്കുമോ? ഞാൻ പരിശോധിച്ചു, PHP 8.2 ആണ്, അത് കുഴപ്പമില്ല. ഫയൽ തന്നെ തകരാറിലായിരിക്കുമോ? ഞാൻ ഒരു പുതിയ പകർപ്പ് ഡൗൺലോഡ് ചെയ്തു, അത് ഓവർറൈറ്റ് ചെയ്തു, പക്ഷേ അത് ഇപ്പോഴും ശൂന്യമാണ്.

വിശദീകരിക്കാനാകാത്ത എന്തോ കാരണത്താൽ, എന്റെ പേര് മാറ്റാൻ ശ്രമിച്ചുകൂടേ എന്ന് ഞാൻ ചിന്തിച്ചു.

ഞാൻ adminer.php എന്നതിന്റെ പേര് adminer1.php എന്ന് മാറ്റി പേജ് പുതുക്കി.

പ്രവേശനം വിജയകരമായിരുന്നു.

ഞാൻ ശരിക്കും അമ്പരന്നു പോയി. അതേ ഫയൽ, അതേ കോഡ്, അതേ സെർവർ, പേര് മാറ്റിയാൽ തന്നെ അതിലേക്ക് പ്രവേശിക്കാൻ കഴിയുമോ? എന്തൊരു നിഗൂഢ യുക്തിയാണിത്?

ഒരു ശൂന്യമായ adminer.php ഫയലിന്റെ പ്രശ്നം

ഇത് ഒരുതരം അന്ധവിശ്വാസമല്ലെന്ന് പിന്നീട് എനിക്ക് മനസ്സിലായി; PHP കാഷിംഗാണ് പ്രശ്‌നത്തിന് കാരണമെന്ന്.

ഒപ്‌കോഡ് കാഷെ എന്നതിന്റെ ചുരുക്കെഴുത്ത് ആയ OPcache, PHP-യുടെ ഒരു പെർഫോമൻസ് ഒപ്റ്റിമൈസേഷൻ എക്സ്റ്റൻഷനാണ്. ഇതിന്റെ തത്വം ലളിതമാണ്: PHP ഒരു ഇന്റർപ്രെറ്റഡ് ഭാഷയാണ്, ഓരോ അഭ്യർത്ഥനയും നടപ്പിലാക്കുന്നതിന് മുമ്പ് PHP കോഡ് ഒപ്‌കോഡിലേക്ക് കംപൈൽ ചെയ്യേണ്ടതുണ്ട്. OPcache കംപൈൽ ചെയ്ത ഫലം മെമ്മറിയിൽ കാഷെ ചെയ്യുന്നു, തുടർന്നുള്ള അഭ്യർത്ഥനകൾക്ക് റീകംപൈലേഷൻ ഇല്ലാതെ നേരിട്ട് കാഷെ ചെയ്ത പതിപ്പ് ഉപയോഗിക്കാൻ അനുവദിക്കുന്നു, ഇത് പ്രകടനത്തിൽ ഗണ്യമായ പുരോഗതിക്ക് കാരണമാകുന്നു.

പക്ഷേ അവിടെയാണ് പ്രശ്നം കിടക്കുന്നത്.

മുമ്പ്, adminer.php "ഫയൽ കണ്ടെത്തിയില്ല" (ഞാൻ തെറ്റായ ഫയൽ അപ്‌ലോഡ് ചെയ്‌തു) എന്ന് പ്രദർശിപ്പിച്ചിരുന്നു, കൂടാതെ OPcache ആ തെറ്റായ ഉള്ളടക്കത്തിന്റെ സമാഹരിച്ച ഫലം കാഷെ ചെയ്‌തിരുന്നു. പിന്നീട്, ഞാൻ adminer.php ശരിയായ കോഡ് ഉപയോഗിച്ച് മാറ്റി, പക്ഷേ OPcache അത് അവഗണിച്ച് മെമ്മറിയിൽ നിന്ന് പഴയ കാഷെ വായിക്കുന്നത് തുടർന്നു, അതിന്റെ ഫലമായി ഒരു ശൂന്യമായ പേജ് അല്ലെങ്കിൽ പഴയ പിശക് സന്ദേശം ലഭിച്ചു.

നിങ്ങൾ അതിനെ adminer1.php എന്ന് പുനർനാമകരണം ചെയ്യുമ്പോൾ, അത് OPcache-നുള്ള പൂർണ്ണമായും പുതിയൊരു ഫയൽ പാത്ത് ആയി മാറുന്നു, കൂടാതെ അത് റീലോഡ് ചെയ്യുകയും ശരിയായി പരിഹരിക്കുകയും ചെയ്യും.

പുതിയൊരു പുസ്തകം വാങ്ങിയതുപോലെയാണ് തോന്നുന്നത്, പക്ഷേ ലൈബ്രറിയുടെ സൂചിക കാർഡിൽ ഇപ്പോഴും പഴയ പുസ്തകത്തിന്റെ കോൾ നമ്പർ ഉണ്ട്. നിങ്ങൾ അത് ഷെൽഫിൽ തിരയാൻ പോകുമ്പോൾ, തീർച്ചയായും അത് ശൂന്യമായിരിക്കും. എന്നാൽ നിങ്ങൾ പുസ്തകത്തിന്റെ പേര് മാറ്റിയാൽ, ലൈബ്രറി നിങ്ങൾക്കായി ഒരു പുതിയ സൂചിക കാർഡ് സൃഷ്ടിക്കും, അപ്പോൾ നിങ്ങൾക്ക് അത് കണ്ടെത്താനാകും.

കാരണം 1: OPcache കാഷെ ശൂന്യമായ ഇടങ്ങൾക്ക് കാരണമാകുന്നു

ഇത് എങ്ങനെ കൈകാര്യം ചെയ്യാം?

PHP-FPM സേവനം പുനരാരംഭിച്ച് OPcache കാഷെ മായ്‌ക്കുക.

# 查看正在运行的PHP版本
php -v

# 重启对应的PHP-FPM（例如PHP 8.5）
sudo systemctl restart php8.5-fpm

# 或者重启所有PHP-FPM服务
sudo systemctl restart php*-fpm

പുനരാരംഭിച്ചതിനുശേഷം, ഫയലിന്റെ പേര് adminer.php എന്ന് തിരികെ നൽകുക, വെബ്‌പേജ് പുതുക്കുക (ബ്രൗസർ പുതുക്കാൻ നിർബന്ധിതമാക്കാൻ Ctrl+F5 അമർത്തുന്നത് ശുപാർശ ചെയ്യുന്നു), പ്രശ്നം പരിഹരിക്കപ്പെടും.

പക്ഷേ കഥ ഇതുവരെ അവസാനിച്ചിട്ടില്ല.

PHP-FPM പുനരാരംഭിച്ചതിനുശേഷം, ഞാൻ adminer.php ഫയൽ തിരികെ മാറ്റി, പേജ് പുതുക്കി, പക്ഷേ അത് ഇപ്പോഴും ശൂന്യമായിരുന്നു. ഞാൻ പൂർണ്ണമായും അമ്പരന്നു.

കാരണം 2: Nginx കോൺഫിഗറേഷൻ നിയമ നിയന്ത്രണങ്ങൾ

ഇത് രണ്ടാമത്തെ സാധ്യമായ കാരണത്തിലേക്ക് നയിക്കുന്നു.

Nginx കോൺഫിഗറേഷൻ ഫയലിൽ adminer.php നിയന്ത്രിക്കുന്ന പ്രത്യേക നിയമങ്ങൾ ഉണ്ടായിരിക്കാം.

ഞാൻ മുമ്പ് HestiaCP പാനലിൽ Fail2Ban കോൺഫിഗർ ചെയ്തിരുന്നു , ബ്രൂട്ട്-ഫോഴ്‌സ് ആക്രമണങ്ങൾ തടയുന്നതിനായി adminer.php-യ്‌ക്കായി ഒരു കൃത്യമായ മാച്ച് റൂൾ എഴുതിയിരുന്നു . റൂൾ adminer.php ഫയൽ നാമത്തെ ഹാർഡ്‌കോഡ് ചെയ്‌തു, അതിനാൽ നിങ്ങൾ അതിനെ adminer1.php എന്ന് പുനർനാമകരണം ചെയ്‌തുകഴിഞ്ഞാൽ, നിങ്ങൾക്ക് ഈ Nginx റൂൾ മറികടക്കാൻ കഴിഞ്ഞു, അത് സാധാരണയായി ആക്‌സസ് ചെയ്യാൻ കഴിയും.

ട്രബിൾഷൂട്ടിംഗ് രീതി ലളിതമാണ്: Nginx കോൺഫിഗറേഷനിൽ ഹാർഡ്-കോഡ് ചെയ്ത എൻട്രികൾക്കായി തിരയുക.

sudo grep -rn "adminer.php" /etc/nginx/

`location = /adminer.php { ... }` പോലുള്ള നിയമങ്ങൾ നിങ്ങൾ കണ്ടെത്തുകയാണെങ്കിൽ, അതിനർത്ഥം Nginx ഈ നിർദ്ദിഷ്ട ഫയൽ നാമം പ്രത്യേകമായി കൈകാര്യം ചെയ്യുന്നു എന്നാണ്. അത് ഇല്ലാതാക്കുകയോ പരിഷ്കരിക്കുകയോ ചെയ്യുക.

കാരണം 3: PHP പിശക് ഡിസ്പ്ലേ ക്രമീകരണങ്ങൾ

മൂന്നാമത്തെ കാരണം കൂടുതൽ സൂക്ഷ്മമാണ്.

PHP സ്ക്രിപ്റ്റ് തടസ്സപ്പെടുകയോ ഒരു പിശക് എറിയുകയോ ചെയ്യുന്നു, പക്ഷേ പേജ് പിശക് ഡിസ്പ്ലേ പ്രവർത്തനരഹിതമാക്കുന്നു (display_errors = ഓഫ്). ഒരു പ്രൊഡക്ഷൻ എൻവയോൺമെന്റിൽ, PHP സ്ഥിരസ്ഥിതിയായി പിശകുകൾ മറയ്ക്കുന്നു, ഒരു ശൂന്യ പേജ് പ്രദർശിപ്പിക്കുന്നു. "./adminer.php" ഉൾപ്പെടുത്താൻ ശ്രമിക്കുന്നതിനിടയിൽ നിങ്ങളുടെ എൻട്രി ഫയൽ (ഉദാ. index.php) ഏതെങ്കിലും കാരണത്താൽ ക്രാഷ് ചെയ്താൽ, പേജ് ശൂന്യമാകും.

ഈ സാഹചര്യത്തിൽ, പിശക് ലോഗ് പരിശോധിക്കുന്നതാണ് ഏറ്റവും വിശ്വസനീയമായ രീതി:

# 查看Nginx错误日志
sudo tail -n 20 /var/log/nginx/error.log

# 或者查看HestiaCP对应域名的error日志
sudo tail -n 20 /var/log/nginx/domains/adminer.domain.com.error.log

വെളുത്ത സ്‌ക്രീനിന്റെ യഥാർത്ഥ കാരണം ലോഗ് നിങ്ങളോട് പറയും.

സത്യം പറഞ്ഞാൽ, error.log പരിശോധിച്ചപ്പോഴാണ് ഞാൻ ഒടുവിൽ പ്രശ്നം കണ്ടെത്തിയത്. adminer.php നിലവിലില്ലാത്ത ഒരു PHP എക്സ്റ്റൻഷൻ വിളിക്കുന്നുണ്ടെന്നും display_errors ഓഫാണെന്നും മനസ്സിലായി, അതിനാൽ പേജ് ശൂന്യമായിരുന്നു, പക്ഷേ പിശക് ലോഗിൽ അത് വ്യക്തമായി രേഖപ്പെടുത്തിയിട്ടുണ്ട്.

പരിഹാരങ്ങളും പ്രശ്നപരിഹാര ഘട്ടങ്ങളും

ഈ സംഭവം എന്നിൽ ആഴത്തിലുള്ള ഒരു മുദ്ര പതിപ്പിച്ചു.

സാങ്കേതിക പ്രശ്നങ്ങൾ പലപ്പോഴും ഉപരിതലത്തിൽ തോന്നുന്നത്ര ലളിതമല്ല. ഒരു ശൂന്യമായ adminer.php ഫയൽ ഒറ്റനോട്ടത്തിൽ ഒരു ഫയൽ പ്രശ്‌നമായി തോന്നിയേക്കാം, പക്ഷേ കൂടുതൽ ആഴത്തിൽ പരിശോധിക്കുമ്പോൾ ഒരു കാഷിംഗ് പ്രശ്‌നം വെളിപ്പെട്ടേക്കാം, പിന്നീട് അത് ഒരു കോൺഫിഗറേഷൻ പ്രശ്‌നമാകാം, തുടർന്ന് കോഡിലെ തന്നെ പ്രശ്‌നമാകാം.

നിങ്ങൾ ഒരു പ്രോഗ്രാമറല്ലെങ്കിൽ, ഇവ നിങ്ങൾക്ക് അപ്രസക്തമാണെന്ന് നിങ്ങൾ കരുതിയേക്കാം. പക്ഷേ ഇതിനെക്കുറിച്ച് ചിന്തിക്കുക: നിങ്ങൾ ഉപയോഗിക്കുന്ന ഓരോ ആപ്പിലും, നിങ്ങൾ സന്ദർശിക്കുന്ന ഓരോ വെബ്‌പേജിലും, സമാനമായ ഒരു സിസ്റ്റം തിരശ്ശീലയ്ക്ക് പിന്നിൽ പ്രവർത്തിക്കുന്നുണ്ട്. കാഷിംഗ്, കോൺഫിഗറേഷൻ, പിശക് കൈകാര്യം ചെയ്യൽ - ഈ ആശയങ്ങൾ യഥാർത്ഥത്തിൽ എല്ലായിടത്തും ഉണ്ട്.

നമ്മളെപ്പോലെ തന്നെ മനുഷ്യരും. പലപ്പോഴും, നമ്മൾ പ്രകടിപ്പിക്കുന്ന "ലക്ഷണങ്ങൾ", ഉദാഹരണത്തിന് നീട്ടിവെക്കൽ, ഉത്കണ്ഠ, ക്ഷോഭം എന്നിവ ഉപരിതലത്തിൽ അലസതയായി തോന്നിയേക്കാം, എന്നാൽ കൂടുതൽ ആഴത്തിൽ കുഴിച്ചെടുക്കുമ്പോൾ, അവ വ്യക്തമല്ലാത്ത ലക്ഷ്യങ്ങൾ, കൂടുതൽ ആഴത്തിൽ കുഴിച്ചെടുക്കൽ, പരാജയഭയം, അതിലും ആഴത്തിൽ, ബാല്യകാല അനുഭവങ്ങൾ രൂപപ്പെടുത്തിയ ഒരു മാനസികാവസ്ഥ എന്നിവ മൂലമാകാം.

യഥാർത്ഥ മൂലകാരണം കണ്ടെത്തിയാൽ മാത്രമേ നമുക്ക് ശരിയായ മരുന്ന് നിർദ്ദേശിക്കാൻ കഴിയൂ.

അവസാനമായി, ഒരു ശൂന്യമായ adminer.php ഫയലിന്റെ പ്രശ്നവും നിങ്ങൾ നേരിടുകയാണെങ്കിൽ, ഈ ക്രമത്തിൽ അത് പരിശോധിക്കുക:

ആദ്യം, PHP-FPM പുനരാരംഭിച്ച് കാഷെ ക്ലിയർ ചെയ്യുക, തുടർന്ന് Nginx കോൺഫിഗറേഷൻ പരിശോധിക്കുക, ഒടുവിൽ error.log പരിശോധിക്കുക.

മിക്ക കേസുകളിലും, പ്രശ്നം പരിഹരിക്കാൻ ആദ്യ രണ്ട് ഘട്ടങ്ങൾ മതിയാകും.

തീർച്ചയായും, അത് ഇപ്പോഴും പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, error.log പരിശോധിക്കുക.

അത് ഉത്തരം നിങ്ങളോട് പറയും.

ഇത്രയും ദൂരം വായിച്ചതിനാൽ, ഇത് സഹായകരമാണെന്ന് തോന്നിയാൽ ദയവായി ലൈക്ക് ചെയ്യുകയും ഷെയർ ചെയ്യുകയും ചെയ്യുക. ആദ്യം അപ്‌ഡേറ്റുകൾ ലഭിക്കണമെങ്കിൽ, നിങ്ങൾക്ക് എന്നെ പിന്തുടരാനും കഴിയും!

എന്റെ ലേഖനം വായിച്ചതിന് നന്ദി. അടുത്ത തവണ കാണാം.