CAKE w/ Adaptive Bandwidth

Community Builds, Projects & Packages
2693

@patrakov can you remind me why:

root@OpenWrt-1:~# cat /root/cake-autorate/test.sh
#!/bin/bash

while read -r line
do
        echo $line
done< <(ping 1.1.1.1)

kills ping process just fine on exit, but when run from:

root@OpenWrt-1:~# cat /etc/init.d/try
#!/bin/sh /etc/rc.common

START=97
STOP=4
USE_PROCD=1

start_service() {
        procd_open_instance
        procd_set_param command "/root/cake-autorate/test.sh"
        procd_close_instance
}

does not?

I think it's related to procd/systemd interfering with normal process management and things like SIGPIPE?

2694

According to my tests, there are three processes involved: test.sh (parent), test.sh (child), and ping. The child seems to be a subshell, but I don't know why it appears here. Anyway all that it does is to wait for the ping process to finish.

procd sends the SIGTERM signal only to the parent process, which indeed terminates. Therefore, the pipe between it and the ping process gets severed from the reader (receiver) end. ping tries to write something there, and, because it is writing to a pipe the other end of which is closed, it gets a SIGPIPE.

Without procd, this signal terminates ping, and then the child test.sh process also finishes waiting for ping to exit, and exits itself, leaving nothing.

With procd, SIGPIPE is ignored, and therefore ping doesn't die, and the test.sh child process continues waiting, in vain. Therefore, two processes remain.

Bad news: in bash, there is no way to restore the "normal" handling of SIGPIPE, this is even documented in the manual page:

Signals ignored upon entry to the shell cannot be trapped or reset.

1 Like
2695

Terrific analysis! Is there by any chance a way to disable the ignoring of SIGPIPE in procd or systemd?

In any case, it seems that perhaps the safest option is to go on retaining the PID and explicitly killing it even though it's less elegant than the pipe teardown mechanism.

2696

Please ignore systemd. It is not relevant to OpenWrt.

And I have checked the code of procd, and can confirm that it sets SIGPIPE to ignored unconditionally.

2697

This commit seemed desirable:

... but hugely problematic for the reasons you have identified.

No way to disable the ignoring of SIGPIPE in procd then? Even if there were to be, perhaps relying on that would be foolhardy.

2698

But you now can encapsulate the whole pinger PID locally inside the parser process an nobody else needs to know, you just keep a single PID. seems easy enough and avoids the need for elaborate process management...

the main loop only needs the maintain and logger PIDs, and maintain the parser PIDs and each parser handles a single binary.... seems pretty clean to me clean enough to be able to not need process management...

2699

I think we can take some inspiration from mwan3: it is also implemented in shell, runs ping and other subprocesses, and is forced to run in an environment where SIGPIPE does not work (which is, in my opinion, an unsupported environment for any shell).

2700

It's been a while since i posted in this thread. life and all that jazz. I have been using the new bash implementation ever since the Lua stopped to work due to reasons already explained. As a user seeking solutions, it's a luxury to have these options. As far as i can determine, the recent bash version does seem to do what i want it to do. But you guys need data. I would love to serve up some here next weekend.

1 Like
2701

Hello.

It would be great if compatibility with other Linux distros could be preserved, as it seems to be the case so far in my x86 Debian setup.

But please, I don't want to be disrespectful or abusive in any way, asking something like this in an ... OpenWrt forum!

Of course you are OpenWrt devs thus your main goal is to produce OpenWrt-tailored code.

Anyway, thanks for the good work so far, and thanks for not kicking me out even if I'm not an OpenWrt user. (I still have OpenWrt in a wifi access point device, though )

2 Likes
2702

If that is true then there is our path forward, trap that term and then initiate a proper staged shutdown, preferably by first asking each process nicely to shut itself down gracefully followed by a SIGKILL (and I mean -9 here the time to ask politely is when sending the shutdown request, so the "talk softly, but carry a big stick" of process management, if you will)

1 Like