Hi Zeping, Thanks for your nice proposal. But I am not sure if removing the go module and introducing service files would be a good alternative. The thing is that not every Unix system uses systemd as an init system there are other service management systems like SysV, Launchd, Upstart. Windows have a service control manager. Now I personally think, we shouldn't write and manage the lifecycle of multiple service files inside Manager-API as we have to continuously work on keeping them up-to-date, fixing bugs etc. Also, this would make an automated process (for the end-user) to a tedious manual task as after the refactoring users need to know how to load, unload, stop service files with that particular service manager.
Instead, we could find a good alternative for the `takama/daemon` package if it is not suitable for the current need. Let the respective developers of that project handle the related problems with that package and we just focus on improving the manager-api. Thanks, Bisakh (https://github.com/bisakhmondal) On Tue, 26 Oct 2021 at 10:49, Bozhong Yu <[email protected]> wrote: > +1. The daemon brings some other problems, for example a user unfamiliar > with APISIX Dashboard's Manager API may install the daemon by mistake. This > will keep the manager-api in the OS and cannot be killed. > > Zeping Bai <[email protected]> 于2021年10月26日周二 下午12:16写道： > > > Hi, everyone. > > > > At present, the back end of APISIX Dashboard's Manager API uses a go > module > > to realize the built-in service daemon management. It is completely > > implemented > > by programming, which brings many use problems. > > > > Now, we can remove this part of the code and use the native way of > > container or > > systemd to manage the lifecycle of the Manager API program. Here is my > > proposal > > [1]. Developers interested in it can review and participate in the > > discussion. > > > > [1] https://github.com/apache/apisix-dashboard/issues/2185 > > > > Best regards! > > Zeping Bai @bzp2010 > > >
