[LEDE-DEV] The procd daemon does not handle correctly the instances

John Crispin john at phrozen.org
Tue Sep 27 08:47:52 PDT 2016



On 27/09/2016 17:34, Lebleu Pierre wrote:
> Hi all,
> 
> I found a bug in the daemon process management. Indeed, when we have several instances of one daemon such as "dnsmasq" and we want to restart only one instance, the other instance is killed by procd. It seems procd updates the second instance and then, kill it.
> 
> Please find the patch :
> diff --git a/service/service.c b/service/service.c
> index 0796adb..9ed07da 100644
> --- a/service/service.c
> +++ b/service/service.c
> @@ -132,8 +132,6 @@ service_update(struct service *s, struct blob_attr **tb, bool add)
>         }
> 
>         if (tb[SERVICE_SET_INSTANCES]) {
> -               if (!add)
> -                       vlist_update(&s->instances);
>                 blobmsg_for_each_attr(cur, tb[SERVICE_SET_INSTANCES], rem) {
>                         service_instance_add(s, cur);
>                 }

this bit is certainly not correct. it simply deactivates the feature for
all services. the actual problem is that procd stores the instances
inside a vlist. this has an update mechanism triggered inside
service_instance_update().

what you want to do is compare in_o and in_n and only trigger
instance_update() if there really was a change. if there is no change
then simply migrate the pid over to the new instance.


> @@ -238,7 +236,7 @@ service_handle_set(struct ubus_context *ctx, struct ubus_object *obj,
>         int ret;
> 
>         blobmsg_parse(service_set_attrs, __SERVICE_SET_MAX, tb, blob_data(msg), blob_len(msg));
> -       cur = tb[SERVICE_ATTR_NAME];
> +       cur = tb[SERVICE_SET_NAME];
>         if (!cur)
>                 return UBUS_STATUS_INVALID_ARGUMENT;

this is a copy paste error but luckily does not cause an error as SET
and ATTR both eval to 0. i have merged this part as a fix.

	John


> 
> 
> Regards,
> 
> Pierre
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 



More information about the Lede-dev mailing list