דברים לא עובדים לך באתר? אולי זה בגלל מחסור במקום

תקלה באתר אינטרנט שטיפלתי בו יכולה ללמד גם על תהליך הדיבאג וגם על סיבה נפוצה לבעיות

הנה סיפור נאה – הגיע אלי בעל עסק לפרויקט הצלה – האתר שלו נפל ולא הצליח לקום ומי שניסה להכנס אליו קיבל שגיאת מסד נתונים של וורדפרס.

לסיפור על תיקון התקלה יש ערך ואני כותב אותו גם בשביל עצמי (כדי שאזכר בפעם הבאה) וגם אולי למי שירצה ללמוד איך מבצעים אנליזה וטיפול לבעיה לא מאוד טריוויאלית.

בדיקת האתר

האתר היה על שרת יעודי לא מנוהל. למרבה הצער, בונה האתר שהעביר אותו לשם לא היה מיומן מספיק בסיסטם ועשה שם כמה שגיאות. האתר החל להיות מאוד איטי בתקופה האחרונה ולאחר כמה ניסיונות פתרון של בונה האתרים הוא הפסיק לעבוד ובונה האתר התפוגג כמובן ברגע שהיה קשה. הלקוח, בעל עסק שנשען משמעותית על המכירות באתר, הגיע אלי במצב בעייתי ולמרבה המזל היה לי פנאי לסייע.

האתר כלל לא עבד כשניגשתי אליו וסבל ממסך לבן ואיכותי. פתרון בעיית המסך הלבן הוא קל יחסית (לחיצה על הקישור מציגה איך פותרים אותו). אבל מייד כשבעיית המסך הלבן נפתרה, גיליתי את שגיאת Cannot connect to Database.

database connection error wordpress

כאשר התקלה הזו מופיעה, הדבר הראשון שאנו בודקים זה מה קרה למסד הנתונים. במקרה הזה השרת המנוהל הפעיל את MariaDB שזהה ל-MySQL. הדבר הראשון שעשיתי זה להתחבר למסד הנתונים באמצעות פקודת mysql כדי לרחרח מה קורה שם. הקלדתי mysql:

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)

מה שקיבלתי זה שגיאה איכותית:

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)

השגיאה הזו אומרת בעצם שהשירות לא באוויר. אם אתם מקבלים אותה, כדאי לבצע ריסטארט למסד הנתונים באמצעות: sudo service mysql restart.

למרבה הצער קיבלתי שגיאה. טוב, זה מסביר למה הוורדפרס לא הצליח להתחבר למסד הנתונים. כי הוא לא למעלה.

Job for mysql.service failed because the control process exited with error code. See "systemctl status mysql.service" and "journalctl -xe" for details.
                                                           [FAILED]

השגיאה הזו היא שגיאה כללית, אבל כן יש בה מידע איך לחפש בלוגים. חלק מהאנשים (גם אני כמובן) יפנו לעולם הגדול של גוגל ויתחילו לחפש לפי פלט השגיאה הזו. שזה דבר לא טוב, כי יש המון שגיאות שיכולות לגרום לשגיאה כללית. הדרך היחידה היא לחפש בלוגים ולנסות להבין מה קרה פה.

איך קוראים את הלוגים? כמה נוח שיש בפלט השגיאה עצמה את הדרך:

systemctl status mysql.service -l

קיבלתי המון לוגים. הלוגים האלו עלולים לבלבל כי יש בהם המון מידע וגם המון שגיאות. בדרך כלל מה שמעניין אותנו זו השגיאה הראשונה. כי מה שקורה הוא שיש שגיאה ואז היא גוררת המון שגיאות אחרות. במקרה הזה השגיאה הראשונה היתה:

Failed to start LSB: start and stop MariaDB.

לא היה יותר מדי מידע אבל זה היה מספיק כדי להבין שאין פה איזו בעית סיסטם, מישהו אחר שמפריע/רוכב על הפורט או משהו דומה. אם יש שגיאה כזו – השלב הבא הוא לבדוק את הלוגים של השירות שנפל. במקרה הזה MariaDB. את הלוגים של מסד הנתונים אנו רואים ב:

cat /var/log/mariadb/mariadb.log

איך ידעתי פשוט חיפשתי בגוגל איפה הלוגים נמצאים ואיפה אפשר לראות אותם.

גם פה – ערימות של מידע והמון שגיאות. הלכתי לשגיאה הראשונה ושם היה כתוב:

2020-06-11  3:40:18 0 [ERROR] mysqld: Can't lock aria control file '/var/lib/mysql/aria_log_control' for exclusive use, error: 11. Will retry for 30 seconds

בדרך כלל כשיש בעיות עם lock file, זה אומר שיש לנו בעיית מקום. גם גיגול של השגיאה הזו מראה שזה החשוד המיידי.

בעיית המקום

נורא קל לשכוח, וכשאני אומר קל לשכוח אני מתכוון לזה שאני שוכח – ששרתים הם בעצם מחשבים לכל דבר. גם מחשבים וירטואלים הם מחשבים שמוקצים להם משאבים ובכללם גם משאבי מקום. ומקום בהארדיסק, יודע כל מי שגדל בשנות התשעים המאוחרות, יכול להגמר.

איך בודקים את זה? עם פקודת df -H וזה מה שקיבלתי:

/dev/sda3        85G   84G     0 100% /

כשאין מקום בהארדיסק, קבצים לא יכולים להיווצר – במקרה הזה קובץ ה-lock של מסד הנתונים. ואז מסד הנתונים לא יכול להתרומם. השלב הבא הוא לנסות להבין איך לעזאזל מערכת של וורדפרס אכלה 85 ג׳יגהביט. בשביל זה אני צריך פקודה אחרת: du.

הפקודה מראה את כל התיקיות והקבצים שיש ב */ – כלומר ב-root.

sudo du -shxc /*
תיקית 73G של /var/

וכך בעצם אפשר לבדוק מה קורה ב-var עם הפקודה

sudo du -shxc /var/*

ולראות את התיקיות העמוסות ולהכנס לכל אחת מהן. כך ראיתי שרוב העומס נמצא בתיקית www. בדיקה מהירה שם עם

sudo du -shxc /var/www/*

הראתה לי שהבעיה היא בכלל ב-vhost העמוסה. וכך בסוף הבנתי שכל העומס מתרכז בקובץ הלוגים:

/var/www/vhosts/THE-SITE.COM/logs

במקרה הזה בחרתי קובץ לוג שאני לא צריך, העתקתי אותו אלי עם scp ומחקתי אותו. ובום. 5 ג׳יגה השתחררו ואז sudo service mysql star הצליח. הבעיה נפתרה.

ראשית בעל העסק היה מאושר מכך שהאתר שלו חזר לפעולה. פתאום כל מיני דברים הסתדרו לו – האיטיות של האתר, הכשלון בלהעלות קבצים ולעשות פעולות – דברים שבונה האתר שלו ניסה לפתור באמצעים משונים ולא באמצעות בדיקה מקיפה. הקש ששבר את גב השרת הוא ריסטארט לשרת ואז מסד הנתונים פשוט לא עלה בגלל המקום.

עכשיו בעצם העבודה האמיתית מתחילה – להבין למה בדיוק הלוגים הצטברו בלי שיש תהליך שמוחק חלק מהם ואם יש בעיות אחרות שנגרמו מהסיפור הזה. קישרתי את בעל העסק לבונת אתרים שאני סומך עליה (רויטל סלומון שהיא בונת אתרים מצוינת) והמשכתי להתנדנד לי בערסל.

פוסטים נוספים שכדאי לקרוא

למפתחי ובוני אתרי אינטרנט

מדריך לשאילתות יעילות ל Chat GPT

כל אחד יכול לשאול את GPT, אבל אם תרצו לשאול אותו שאלות על תכנות – יש כמה שיטות וטיפים ליעל את העבודה מולו.

פתרונות ומאמרים על פיתוח אינטרנט

יישום של nonce על מנת להגן מפני התקפות injection

בפוסט הקודם הסברתי על hash עם CSP על משאבי inline – שזה נחמד ומעולה אבל פחות ישים בעולם האמיתי שבו בדרך כלל התוכן ה-inline (בין

תמונה מצוירת של רובוט שמנקה HTML
יסודות בתכנות

סניטציה – למה זה חשוב

הסבר על טכניקה פשוטה וידועה מאד שאנו מפעילים על מידע לפני שאנחנו מציגים אותו ב-HTML באפליקציה או באתר.

גלילה לראש העמוד