You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The daily2 script successfully restarts the server every night, but when it does so the server partially hangs. It is unclear what is occurring, as the server does respond the basic information PING packets but will not respond to SYN with SYN-ACK and thus cannot be joined. Running the daily2 script manually does not have this problem.
The scripts involved had some bugs due to being so old, but these were fixed, however this issue still occurs. The current suspected cause is a permission difference between the CRON and normal user execution, though both appear to use the same user account.
The text was updated successfully, but these errors were encountered:
Note: An attempt was made for the server to auto-detect this state in the restart2 script which is run every 5 min to restart the server if it is offline and correct it. A special program syntest2 will attempt a SYN, SYN-ACK, ACK handshake with the server and if it fails, trigger a restart. Like the daily2 script, this fails to start the server in a functional state when run via CRON but works when executed by user. This script does however properly detect the server is in this inaccessible state in both cases.
This is caused by the CRON not properly keeping shell variable scope. The scripts can be adjusted to work around this, but it is only an issue if using shell vars to work around automatic IP detection issues.
The
daily2
script successfully restarts the server every night, but when it does so the server partially hangs. It is unclear what is occurring, as the server does respond the basic information PING packets but will not respond to SYN with SYN-ACK and thus cannot be joined. Running thedaily2
script manually does not have this problem.The scripts involved had some bugs due to being so old, but these were fixed, however this issue still occurs. The current suspected cause is a permission difference between the CRON and normal user execution, though both appear to use the same user account.
The text was updated successfully, but these errors were encountered: