Tôi có ba suy nghĩ về các giải pháp khả thi cho vấn đề của bạn:
1. Bạn đã nói:
Nếu tôi chạy auto_reboot.sh theo cách thủ công, nó sẽ khởi động lại khi kiểm tra ping không thành công. Nhưng chạy từ crontab, nó không hoạt động :)
Thông thường, khi một lệnh chạy đúng trong shell tương tác của bạn (từ CLI), nhưng không chạy đúng trong cron đó là do sự khác biệt trong môi trường; ví dụ. cron có một ĐƯỜNG khác với bạn làm từ trình bao tương tác của mình. Tiêu biểu, các cron môi trường là: ĐƯỜNG=/usr/bin:/bin. Bất kỳ tập lệnh nào bạn chạy chạy theo cron sẽ không thể tìm thấy các tệp thực thi không có trên PATH.
Bên cạnh đó, bạn có thể kiểm tra cron môi trường trên hệ thống của bạn bằng cách chạy env sử dụng của bạn crontab:
* * * * * /usr/bin/env > /my/cronlog/location/mycronenvironment.txt 2>&1
trong bạn auto_reboot.sh, bạn đã thất bại trong việc sử dụng một thông số kỹ thuật đường dẫn đầy đủ vì khởi động lại. Như khởi động lại thường được tìm thấy trong /sbin/khởi động lại, và /sbin có thể không trong PATH được sử dụng bởi cron, đây là một vấn đề tiềm ẩn.
Do đó, tôi khuyên bạn nên xác minh môi trường (PATH) được sử dụng bởi cronvà kiểm tra kỹ tất cả các lệnh của bạn có phải là: 1) trên cron ĐƯỜNG, hoặc 2) sử dụng một đặc tả đường dẫn đầy đủ.
2. Bạn sử dụng hết mọi thứ /nguồn gốc danh mục
Thông thường, /nguồn gốc không được sử dụng cho người dùng kịch bản. Có lẽ bạn đang sử dụng sudo? Hoặc, có lẽ bạn đã thực hiện một su để trở thành root? Nếu đây là trường hợp, tôi sẽ bình luận rằng đây không phải là thực hành tốt nhất, mặc dù nó vẫn có thể hoạt động. tôi cảm thấy thực hành tốt nhất là để sử dụng sudo từ của bạn người dùng tài khoản cho bất kỳ sự leo thang đặc quyền nào bạn cần.
Không cố tỏ ra khoa trương, tôi muốn nói rằng nguồn gốc tài khoản có một crontab chạy độc lập với bất kỳ người dùng crontab. Ngoài ra, các crontab gốc không yêu cầu sudo được sử dụng - mọi thứ được thực hiện trong crontab gốc được thực hiện với nguồn gốc đặc quyền.
Tất cả những gì đã nói, tôi thấy cuộc gọi đến khởi động lại trong tập lệnh của bạn - một lệnh đòi hỏi quyền root để chạy. Điều này sẽ hoạt động như bạn đã viết nó chỉ có khi được sử dụng trong crontab gốc. Câu hỏi của bạn không cho biết bạn có đang sử dụng hay không su hoặc sudo, và vì vậy tôi đã xem qua phần này với nỗ lực làm rõ hai điểm:
- Nếu là của bạn
cron công việc yêu cầu nguồn gốc đặc quyền, nó có lẽ tốt nhất để chạy công việc đó từ crontab gốc. Cách khác là sử dụng sudo trong một người dùng crontab điều này có khả năng gây khó xử nếu cần xác thực cho sudo - như thường lệ.
- Các
crontab gốc có thể được truy cập từ tài khoản người dùng thông thường chỉ bằng cách sử dụng Sudo crontab -e; tức là người ta không bắt buộc phải su đến nguồn gốc để truy cập vào crontab gốc.
3. Bạn có thể gặp lỗi logic trong tập lệnh của mình
Như đã chỉ ra trong câu trả lời khác, không rõ ràng là bạn có thể dựa vào giá trị của rc từ của bạn ping.sh kịch bản như một điều kiện cho khởi động lại. Thật không may, đây có phải là vấn đề hay không lại bị che lấp bởi hai phiên bản khác nhau của ping.sh trong câu hỏi của bạn - không rõ liệu bạn có đang sử dụng phiên bản đầu tiên hay không:
#!/bin/zsh
((count = 10)) # Số tối đa để thử.
while [[ $count -ne 0 ]] ; làm
ping -c 1 8.8.8.8 # Thử một lần.
rc=$?
hoặc phiên bản thứ hai:
#!/bin/zsh
((count = 10)) # Số tối đa để thử.
while [[ $count -ne 0 ]] ; làm
/usr/bin/ping -c 1 8.8.8.8 >> /root/loadrc/crontab.log 2>&1
tiếng vang "bước -> 2" >> /root/loadrc/crontab.log
rc=$?
Đúng như lựa chọn cá nhân của tôi, tôi muốn kết hợp mã từ hai tập lệnh này (ping.sh và auto_reboot.sh) thành một tập lệnh vì nó có vẻ đơn giản hơn đối với tôi, nhưng bạn có thể có lý do chính đáng để thực hiện theo cách này và không có lý do gì nó không hoạt động nếu được thực hiện đúng cách.
