[LEDE-DEV] procd: service instance restart does not wait for old process to be closed before lanching the new one
Hi John, One of the daemons I use takes sometime a couple of seconds to close after receiving SIGTERM, so when I issue "/etc/init.d/mydaemon restart" there will be 2 instances of that service running in parallel until the initial instance will finally manage to handle the SIGTERM signal. This daemon registers its own ubus object, but new instance will fail to register its object due to name conflict with an object that is already existing. The root cause of this defect is the way procd restarts a service by issuing a service_stop followed immediately by a service_start: 1) service_stop call translates to - instance_stop() -> send SIGTERM signal to the old instance - instance_free() -> call uloop_process_delete(), which means in->proc.pending will be set to 0 2) sevice_start will launch the new instance becaise previous process has been already deleted Shouldn't uloop_process_delete() be called only when process was closed, as it is the case in uloop.c? If so, instance_start() should at least set restart to 1 when (in->proc.pending && in->halt). And isn't a bit too optimistic to assume all daemons will be stopped by SIGTERM? BR, Alin ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] procd: service instance restart does not wait for old process to be closed before lanching the new one
Hi John, One of the daemons I use takes sometime a couple of seconds to close after receiving SIGTERM, so when I issue "/etc/init.d/mydaemon restart" there will be 2 instances of that service running in parallel until the initial instance will finally manage to handle the SIGTERM signal. This daemon registers its own ubus object, but new instance will fail to register its object due to name conflict with an object that is already existing. The root cause of this defect is the way procd restarts a service by issuing a service_stop followed immediately by a service_start: 1) service_stop call translates to - instance_stop() -> send SIGTERM signal to the old instance - instance_free() -> call uloop_process_delete(), which means in->proc.pending will be set to 0 2) sevice_start will launch the new instance becaise previous process has been already deleted Shouldn't uloop_process_delete() be called only when process was closed, as it is the case in uloop.c? If so, instance_start() should at least set restart to 1 when (in->proc.pending && in->halt). And isn't a bit too optimistic to assume all daemons will be stopped by SIGTERM? BR, Alin ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] procd: service instance restart does not wait for old process to be closed before lanching the new one
On 08/02/2017 15:55, Alin Năstac wrote: > Hi John, > > One of the daemons I use takes sometime a couple of seconds to close > after receiving SIGTERM, so when I issue "/etc/init.d/mydaemon > restart" there will be 2 instances of that service running in parallel > until the initial instance will finally manage to handle the SIGTERM > signal. This daemon registers its own ubus object, but new instance > will fail to register its object due to name conflict with an object > that is already existing. > > The root cause of this defect is the way procd restarts a service by > issuing a service_stop followed immediately by a service_start: > 1) service_stop call translates to > - instance_stop() -> send SIGTERM signal to the old instance > - instance_free() -> call uloop_process_delete(), which means > in->proc.pending will be set to 0 > 2) sevice_start will launch the new instance becaise previous > process has been already deleted > > Shouldn't uloop_process_delete() be called only when process was > closed, as it is the case in uloop.c? If so, instance_start() should > at least set restart to 1 when (in->proc.pending && in->halt). > > And isn't a bit too optimistic to assume all daemons will be stopped by > SIGTERM? Hi, probably, feel free to send a patch to fix the issue. we can help test it. John > BR, > Alin > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev