[LEDE-DEV] [PATCH] procd: add cancel_timeout on rc scripts when a runtime_timeout is specified
Enable procd to restrict the execution time of a rc scripts during shutdown,
even
when a script ignores the SIGTERM signal by insisting after 10s with a SIGKILL.
Signed-off-by: Jurgen Van Ham
---
file /etc/rc.d/K01test reproduces the problem that this patch addresses.
#!/bin/sh
h_sigterm() {
echo $0 SIGTERM > /dev/console
}
stop() {
local x=0
while true; do
x=$(($x+1))
echo $0 PING $x > /dev/console
sleep 1
done
}
trap h_sigterm SIGTERM
case "$1" in
stop|shutdown)
stop
;;
esac
creating the above file results in a board that cannot complete the 'reboot'
command.
rcS.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/rcS.c b/rcS.c
index 1e38d39..0208a75 100644
--- a/rcS.c
+++ b/rcS.c
@@ -121,8 +121,10 @@ static void add_initd(struct runqueue *q, char *file, char
*param)
}
s->proc.task.type = &initd_type;
s->proc.task.complete = q_initd_complete;
- if (!strcmp(param, "stop") || !strcmp(param, "shutdown"))
+ if (!strcmp(param, "stop") || !strcmp(param, "shutdown")) {
s->proc.task.run_timeout = 15000;
+ s->proc.task.cancel_timeout = 1;
+ }
s->param = p;
s->file = f;
strcpy(s->param, param);
--
1.7.9.5
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Support for more than a single overlay, which is selected at boot time
Hi all,
I want to support multiple (currently just two) configurations on a
single device. One of these configurations is chosen at boot time.
Instead of saving and restoring the configuration each time, I came up
with a solution that relies on extending the overlay by splitting it
into two banks. There can be more than two, but I only need two called
'bank_0' and 'bank_1'
This relies on splitting the overlay file system into two (or more)
different banks, which are implemented as directories in the root of
the overlay file system. Separate file systems would require a
decision how to split the size of the single overlay into two overlays
that do not always have the same size.
Until now the writable /overlay (jffs2 or other) partition is mounted
as the upperdir over the /rom squashfs partition as its lowerdir.
Instead, I consider to replace this /overlay mount by the subdirs
/overlay/bank_1 or /overlay_bank_2 by modifying the code of mount_root
from the fstools package.
The mount_root program read the environment variable 'OVERLAY_BANK'
that is set by modifying two files: /lib/preinit/80_mount_root' and
'/etc/init.d/done' base-files/files. Using an environment variable
keeps the selection of the overlay bank in scripts. The alternative
would be require to integrate the selection of the bank at boot time
into the mount_root program, but that ties the implementation to
specific hardware.
At a high level, I modified the mount_root program to use
'/overlay/${OVERLAY_BANK}/' instead of '/overlay/'. When /overlay does
not yet contain the directory ${OVERLAY_BANK}, it creates this
directory.
I can imagine that this can also be useful to test new firmware and
make it possible to revert the upgrade by moving back to the previous
overlay bank.
Before polishing my experimental implementation and sending it as a
patch to the mailinglist, I'd like to know whether someone else had to
deal with such requirement, or sees different ways to create a device
that can boot with one out of several configurations.
Regards,
Jurgen
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Support for more than a single overlay, which is selected at boot time
Hi,
This solution would work for the uci configuration. This device uses
daemons that keep state (e.g., in an sql database) that is not part of
the
uci files together with binary logs that are are used over boots.
In theory it is possible to use for each of this daemons two
directories and chose by mean of a symlink the active one,
but then a system to change the links for each directory at boot time,
with can also leads to inconsistencies when Murphy strikes
and we boot with a situation where not all symlinks are created to
point to the active configuration.
/etc/config -> /etc/config1
/state/sql -> /state/sql2
Regards,
Jurgen
On Thu, Mar 9, 2017 at 5:04 AM, Philip Prindeville
wrote:
>
>> On Mar 7, 2017, at 6:15 AM, Jurgen Van Ham wrote:
>>
>> Hi all,
>>
>> I want to support multiple (currently just two) configurations on a
>> single device. One of these configurations is chosen at boot time.
>> Instead of saving and restoring the configuration each time, I came up
>> with a solution that relies on extending the overlay by splitting it
>> into two banks. There can be more than two, but I only need two called
>> 'bank_0' and 'bank_1'
>>
>> This relies on splitting the overlay file system into two (or more)
>> different banks, which are implemented as directories in the root of
>> the overlay file system. Separate file systems would require a
>> decision how to split the size of the single overlay into two overlays
>> that do not always have the same size.
>
> Um…. maybe I’m missing something but you could also have:
>
> /etc/config1/
> /etc/config2/
>
> and have /etc/config/ be a symlink to ../config1 or ../config2.
>
> Or is that too simple to possibly work?
>
> -Philip
>
>
>>
>> Until now the writable /overlay (jffs2 or other) partition is mounted
>> as the upperdir over the /rom squashfs partition as its lowerdir.
>> Instead, I consider to replace this /overlay mount by the subdirs
>> /overlay/bank_1 or /overlay_bank_2 by modifying the code of mount_root
>> from the fstools package.
>>
>> The mount_root program read the environment variable 'OVERLAY_BANK'
>> that is set by modifying two files: /lib/preinit/80_mount_root' and
>> '/etc/init.d/done' base-files/files. Using an environment variable
>> keeps the selection of the overlay bank in scripts. The alternative
>> would be require to integrate the selection of the bank at boot time
>> into the mount_root program, but that ties the implementation to
>> specific hardware.
>>
>> At a high level, I modified the mount_root program to use
>> '/overlay/${OVERLAY_BANK}/' instead of '/overlay/'. When /overlay does
>> not yet contain the directory ${OVERLAY_BANK}, it creates this
>> directory.
>>
>> I can imagine that this can also be useful to test new firmware and
>> make it possible to revert the upgrade by moving back to the previous
>> overlay bank.
>>
>> Before polishing my experimental implementation and sending it as a
>> patch to the mailinglist, I'd like to know whether someone else had to
>> deal with such requirement, or sees different ways to create a device
>> that can boot with one out of several configurations.
>>
>> Regards,
>>
>> Jurgen
>
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Procd instance pidfiles remain after daemon dies unexpectedly
Dear all, Procd supports instance_writepid and instance_removepid in the file instance.c. The removepid is called when stopping a daemon or restarting it. However, when a daemon dies and it is not configured to respawn the pidfile is not removed. When other daemon watch the pidfile because they rely on the daemon they cannot rely to stop when the pidfile disappears. This other daemon cannot just continue after procd would respawn the died daemon. Before restarting the procd managed daemon, the depending daemons need to stop. Would a fix in the function instance_exit be the right solution to remove the pid after dying without a configured respawn? Is there a reason to keep a pidfile after a daemon terminates without any procd request. regards, ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] a Procd alternative to respawn for a died daemon?
Dear all, The current version of procd can respond to a failing daemon by respawning it. This works for daemons that no (or not many) daemons rely on. Is there an elegant way to cause a restart after critical service dies. With critical I mean that a mere restart would require too many actions from other daemons. I can imagine a work around by replacing the "procd_set_param command " in an init file by "procd_set_param command /bin/critical_.sh" and using a file /bin/critical_.sh that first starts .sh and when it returns triggers a reboot. This could lead to a reboot during a intended shutdown. Does it make sense to support an extra procd_set_param (e.g., 'reboot') that explicitly triggers a reboot when its 'command' dies? This reboot could either have a time argument or a script that is executed after the daemon fails. I don't see much reason for executing a script, but maybe this makes it possible to support more advanced recovery scenarios instead of restarting the device. Do other developers have other (better) ideas how to deal with a dying daemon, that is more complex to restart because it requires actions from other daemon to deal with its restart. regards, ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Procd instance pidfiles remain after daemon dies unexpectedly
Ok, I'll try this and once I confirm that it behaves as expected, I'll
publish the patch here.
On Fri, Jul 1, 2016 at 10:26 AM, John Crispin wrote:
>
>
> On 01/07/2016 08:45, Jurgen Van Ham wrote:
>> Dear all,
>>
>> Procd supports instance_writepid and instance_removepid in the file
>> instance.c.
>> The removepid is called when stopping a daemon or restarting it.
>> However, when a daemon
>> dies and it is not configured to respawn the pidfile is not removed.
>>
>>
>> When other daemon watch the pidfile because they rely on the daemon
>> they cannot rely to stop when the pidfile disappears. This other
>> daemon cannot just continue after procd would respawn the died daemon.
>> Before restarting the procd managed daemon, the depending daemons need
>> to stop.
>>
>> Would a fix in the function instance_exit be the right solution to
>> remove the pid after dying without a configured respawn?
>> Is there a reason to keep a pidfile after a daemon terminates without
>> any procd request.
>
> pidfile support was added at some point and this is a corner case that
> you stumbled across that we failed to add. instance_exit() would be the
> correct place to add this. having had a quick look just addin an else {}
> at the end of the if clause is probably what should be done to fix this
>
> John
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] remove pidfile when daemon dies and is not respawned
When a daemon dies unexpectedly and it will not be respawned, the
pidfile needs to be removed. (halt is set as !respawn)
--- a/service/instance.c2016-07-01 14:22:53.507113056 +0200
+++ b/service/instance.c2016-07-01 14:24:38.541075073 +0200
@@ -513,7 +513,7 @@
uloop_timeout_cancel(&in->timeout);
if (in->halt) {
- /* no action */
+ instance_removepid(in);
} else if (in->restart) {
instance_start(in);
} else if (in->respawn) {
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] procd: remove pidfile after unexpected termination without respawn
When procd detects a daemon halts and it is not configured to
be respawned, the pidfile has to be removed.
Signed-off-by: Jurgen Van Ham
---
service/instance.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/service/instance.c b/service/instance.c
index dccf4b4..d7d1f82 100644
--- a/service/instance.c
+++ b/service/instance.c
@@ -513,7 +513,7 @@ instance_exit(struct uloop_process *p, int ret)
uloop_timeout_cancel(&in->timeout);
if (in->halt) {
- /* no action */
+ instance_removepid(in);
} else if (in->restart) {
instance_start(in);
} else if (in->respawn) {
--
1.7.9.5
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] procd: instance_stop causes a call to instance_removepid via instance_exit, no need to do this already when the instance will be stopped.
Signed-off-by: Jurgen Van Ham --- service/instance.c |1 - 1 file changed, 1 deletion(-) diff --git a/service/instance.c b/service/instance.c index d7d1f82..8f7835a 100644 --- a/service/instance.c +++ b/service/instance.c @@ -541,7 +541,6 @@ instance_stop(struct service_instance *in) in->halt = true; in->restart = in->respawn = false; kill(in->proc.pid, SIGTERM); - instance_removepid(in); } static void -- 1.7.9.5 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
