After upgrading from AnQiCMS 2.x version to 3.x version, is the PID detection in the old `start.sh` scheduled task still applicable?
As a senior CMS website operation personnel of a security company, I am well aware of the importance of system stability and management efficiency for content operation.About the issue you raised regarding the upgrade from AnQiCMS 2.x to 3.x, the oldstart.shThe issue of whether the PID detection in the scheduled task is still applicable, I can provide you with a detailed answer.
In the AnQiCMS 2.x version, in order to ensure that the AnQiCMS application written in Go language can run stably for a long time, especially after server restart or program unexpected exit, we usually adopt a classic Linux process guardian strategy.This is,start.shThe script plays a core role. The main function of this script is to determine whether the AnQiCMS service is running by checking if a specific process ID (PID) exists.If it detects that the service is not running, it will executenohupThe command starts the AnQiCMS executable file in the background and configures the script for the Linux systemcrontabScheduled task, usually executed every minute to achieve program automatic monitoring and restart.This mechanism is simple and effective, making up for the lack of direct background restart support in the 2.x version.
However, with AnQiCMS evolving from version 2.x to 3.x, the project's deployment and management methods have undergone significant development, particularly in terms of usability and integration.According to the installation and upgrade guide of AnQiCMS 3.x, the system strongly recommends that users adopt a more modern and integrated deployment method, such as deploying through the "Go project" function of server management tools like Baota panel.This new deployment paradigm aims to simplify the operational burden of users and provide more comprehensive service management capabilities.
This means that after you upgrade AnQiCMS to version 3.x, the originalstart.shThe PID detection mechanism in the scheduled task is no longer recommended or required.Although theoretically, the core Go executable file of AnQiCMS may still be in the 3.x version, it may still beanqicmsname will run, and the oldps -ef | grep '\<anqicms\>'The command can still detect its PID, but the management responsibility of the service has been transferred from the manually configuredcrontabThe script has been transferred to the management interface provided by the new deployment environment.
For example, when deploying AnQiCMS 3.x through the 'Go project' of Baota panel, the panel itself is responsible for starting, stopping, restarting, and monitoring the status of the Go application.The panel is built with its own process guardian and management logic, which can manage the Go service lifecycle more intelligently and comprehensively.This integrated management approach not only provides a convenient backend operation interface, but also usually includes advanced features such as log management, resource monitoring, etc., far beyond simplestart.shThe ability that the script can provide.
Therefore, the upgrade recommendation for AnqiCMS 3.x versions explicitly states that after migrating to the new version, you should first stop the project using the scheduled task, then delete the scheduled task, and then add it back according to the recommended 'Go project' deployment method.This is to avoid potential conflicts between new and old management mechanisms, ensuring that the system can fully utilize the management convenience and stability improvements brought by the 3.x version.Continue using the old onestart.shScript, may cause services to be restarted repeatedly, log confusion, resource waste, and may even interfere with the normal management behavior of the newly deployed environment, thereby introducing unnecessary complexity or unstable factors.
In summary, although oldstart.shThe PID detection command in the script may still be able to identify the AnQiCMS 3.x process, but its applicability in the overall system management architecture has been lost.AnQiCMS 3.x encourages users to adopt more advanced deployment and management strategies to achieve more efficient and reliable website operations.
Common questions
Has AnQiCMS 3.x completely abandoned the background process management script?Yes, the AnQiCMS 3.x version is designed to simplify deployment and management, especially recommended for deploying 'Go project' through integrated environments such as Baota panel.Under this new deployment mode, the background management panel automatically takes over the functions of program startup, shutdown, restart, and process protection, so users no longer need to manually write and maintain themstart.shsuch process management scripts.
How should I manage the AnQiCMS 3.x process if I haven't used panel management tools like Baota?If your server environment does not use Baota Panel, or you choose to manually deploy AnQiCMS 3.x via the command line, you may consider using some professional process management tools, such assystemdorSupervisorReplace the old onestart.shscript. These tools can provide more robust process protection, log management, and resource control features to ensure that the AnQiCMS service can run stably under various conditions.The specific configuration method will vary depending on the process management tool you choose, but the core idea is to let these tools be responsible for the lifecycle management of the AnQiCMS application.
Keep the old onestart.shWhat specific problems will the script cause?Keep the old onestart.shThe script may cause conflicts in multiple process management. For example, if the Baota panel has already started and is protecting AnQiCMS, and your oldcrontabtask instart.shThe script detects that the process does not exist (it may be due to some reason that it has not been able to be accessed temporarily)psCommand capture), it may try to restart AnQiCMS again, which may cause multiple instances of the same service to run, leading to port conflicts, resource waste, and even issues such as inconsistent data.In addition, the new version may have optimized the startup logic or dependencies, and the old script may not handle them correctly, leading to startup failure or exceptions.