Closed Quba1 closed 1 year ago
rany2
commented
1 year ago Did you copy the new service? Are you sure it's using the launcher? If you updated from an older service file, make sure to try the following:
Quba1
commented
1 year ago Did you copy the new service? Are you sure it's using the launcher? If you updated from an older service file, make sure to try the following:
* service cake-autorate disable * copy the new cake-autorate service file to /etc/init.d * enable cake-autorate
I used the installer for updating to master as suggested in #156, but I will try your suggestion.
Quba1
commented
1 year ago I have just noticed that secondary interface stopped logging DATA. From logs its seems that this issue occurs after connection becomes idle, and after that some non-standard things happen.
Quba1
commented
1 year ago I used the installer for updating to master as suggested in #156, but I will try your suggestion.
I've made sure that I am using latest cake-autorate and _launcher files and starting/stopping service worked well couple times. After stopping it the third time, these are leftover processes:
4267 root 2644 S {cake-autorate.s} /bin/bash /root/cake-autorate/cake-autorate.sh /root/cake-autorate/cake-autorate_config.secondary.sh
4295 root 2520 S {cake-autorate.s} /bin/bash /root/cake-autorate/cake-autorate.sh /root/cake-autorate/cake-autorate_config.secondary.sh
4317 root 2520 S {cake-autorate.s} /bin/bash /root/cake-autorate/cake-autorate.sh /root/cake-autorate/cake-autorate_config.secondary.sh
4353 root 2560 S {cake-autorate.s} /bin/bash /root/cake-autorate/cake-autorate.sh /root/cake-autorate/cake-autorate_config.secondary.sh
4418 root 2664 S {cake-autorate.s} /bin/bash /root/cake-autorate/cake-autorate.sh /root/cake-autorate/cake-autorate_config.secondary.sh
6353 root 2524 S {cake-autorate.s} /bin/bash /root/cake-autorate/cake-autorate.sh /root/cake-autorate/cake-autorate_config.secondary.sh#!/bin/bash
cake_instances=(/root/cake-autorate/cake-autorate_config*sh)
cake_instance_pids=()
trap kill_cake_instances INT TERM EXIT
kill_cake_instances()
{
trap true INT TERM EXIT
echo "Killing all instances of cake one-by-one now."
for ((cake_instance=0; cake_instance<${#cake_instances[@]}; cake_instance++))
do
kill "${cake_instance_pids[${cake_instance}]}" 2>/dev/null || true
done
wait
trap - INT TERM EXIT
}
for cake_instance in "${cake_instances[@]}"
do
/root/cake-autorate/cake-autorate.sh "${cake_instance}" &
cake_instance_pids+=(${!})
done
waitcan you try this instead?
Quba1
commented
1 year ago Trying the updated version leaves those processes running after the first try:
8953 root 2644 S {cake-autorate.s} /bin/bash /root/cake-autorate/cake-autorate.sh /root/cake-autorate/cake-autorate_config.primary.sh
8960 root 2520 S {cake-autorate.s} /bin/bash /root/cake-autorate/cake-autorate.sh /root/cake-autorate/cake-autorate_config.primary.sh
8976 root 2520 S {cake-autorate.s} /bin/bash /root/cake-autorate/cake-autorate.sh /root/cake-autorate/cake-autorate_config.primary.sh
9016 root 2560 R {cake-autorate.s} /bin/bash /root/cake-autorate/cake-autorate.sh /root/cake-autorate/cake-autorate_config.primary.sh
9081 root 2700 S {cake-autorate.s} /bin/bash /root/cake-autorate/cake-autorate.sh /root/cake-autorate/cake-autorate_config.primary.sh
10520 root 2608 S {cake-autorate.s} /bin/bash /root/cake-autorate/cake-autorate.sh /root/cake-autorate/cake-autorate_config.primary.sh#!/bin/bash
cake_instances=(/root/cake-autorate/cake-autorate_config*sh)
cake_instance_pids=()
trap kill_cake_instances INT TERM EXIT
kill_cake_instances()
{
trap true INT TERM EXIT
echo "Killing all instances of cake one-by-one now."
kill "${cake_instance_pids[@]}" 2>/dev/null || true
wait "${cake_instance_pids[@]}"
trap - INT TERM EXIT
}
for cake_instance in "${cake_instances[@]}"
do
/root/cake-autorate/cake-autorate.sh "${cake_instance}" &
cake_instance_pids+=(${!})
done
waitHow about this variant?
Quba1
commented
1 year ago Still the same thing :( cake-autorate_launcher.sh stayed active for a little while but the processes didn't stop
rany2
commented
1 year ago Last chance, if this doesn't work I'll look deeper into this:
#!/bin/bash
set -eu
export PROC_STATE_FILE=/var/run/cake-autorate-launcher
export PROC_STATE_FILE_LOCK="${PROC_STATE_FILE}.lock"
. /root/cake-autorate/cake-autorate_lib.sh
cake_instances=(/root/cake-autorate/cake-autorate_config*sh)
trap kill_cake_instances INT TERM EXIT
kill_cake_instances()
{
trap true INT TERM EXIT
echo "Killing all instances of cake one-by-one now."
for cake_instance in "${cake_instances[@]}"
do
proc_man_stop "${cake_instance}"
done
trap - INT TERM EXIT
}
for cake_instance in "${cake_instances[@]}"
do
proc_man_start "${cake_instance}" bash /root/cake-autorate/cake-autorate.sh "${cake_instance}"
done
waitUnfortunately, no good news - cake-autorate service now doesn't start at all.
Thanks a lot tho for your effort in trying to solve that.
rany2
commented
1 year ago Anything interesting if you run the launcher directly? (no service)
Quba1
commented
1 year ago root@OpenWrt:~/cake-autorate# ./cake-autorate_launcher.sh
Killing all instances of cake one-by-one now.Replace that final wait with proc_man_wait ${cake_instances[0]}
Quba1
commented
1 year ago Still the same result
rany2
commented
1 year ago Oh very sorry, you need cake_instances=(/root/cake-autorate/cake-autorate_config*sh) at the top. I have no idea why I removed that
Quba1
commented
1 year ago Currently it is in line 8, should I move it before the exports?
rany2
commented
1 year ago Oh nevermind, I thought I removed it. It's not the issue, will have to take a look later then
rany2
commented
1 year ago Could you quickly try to remove the set -eu line at the very top? Edit: also delete /var/run/cake-autorate-launcher if it exists
Quba1
commented
1 year ago Now it worked.
Should I try running it as a service as well?
rany2
commented
1 year ago Sure
Quba1
commented
1 year ago Now it worked.
After that message I noticed your edit about removing /var/run/cake-autorate-launcher. It contained:
root@OpenWrt:/tmp/run# cat cake-autorate-launcher
/root/cake-autorate/cake-autorate_config.primary.sh=-1
/root/cake-autorate/cake-autorate_config.secondary.sh=-1After deleting it, cake-autorate_launcher started but I couldn't kill it with Ctrl+C and it left some cake-autorate processes alive.
Edit: Also after trying Ctrl+C for the first time, the script started printing only LOAD statements, which is a similar behaviour to what I have seen previously in logs. Supposedly, those two issues are related...?
rany2
commented
1 year ago Yes that's normal, I meant to delete it before running the launcher
Quba1
commented
1 year ago Success 🎉 cake-autorate service started and stopped correctly consecutively for several times.
Thanks a lot for your help.
I will update if issue with logging persists.
Then final version of the script is
#!/bin/bash
export PROC_STATE_FILE=/var/run/cake-autorate-launcher
export PROC_STATE_FILE_LOCK="${PROC_STATE_FILE}.lock"
. /root/cake-autorate/cake-autorate_lib.sh
cake_instances=(/root/cake-autorate/cake-autorate_config*sh)
trap kill_cake_instances INT TERM EXIT
kill_cake_instances()
{
trap true INT TERM EXIT
echo "Killing all instances of cake one-by-one now."
for cake_instance in "${cake_instances[@]}"
do
proc_man_stop "${cake_instance}"
done
trap - INT TERM EXIT
}
for cake_instance in "${cake_instances[@]}"
do
proc_man_start "${cake_instance}" bash /root/cake-autorate/cake-autorate.sh "${cake_instance}"
done
proc_man_wait ${cake_instances[0]}
Edit: The issue with logging unfortunately still persists.
rany2
commented
1 year ago Edit: The issue with logging unfortunately still persists.
What issue with logging are you referring to?
Quba1
commented
1 year ago What issue with logging are you referring to?
I have just noticed that secondary interface stopped logging
DATA. From logs its seems that this issue occurs after connection becomes idle, and after that some non-standard things happen.
This one. But I don't think it's related to launcher, rather to running cake-autorate with mwan in general.
lynxthecat
commented
1 year ago @patrakov do you have experience running multiple instances at the same time or did you only ever test running one with your mwan3 setup?
patrakov
commented
1 year ago For testing, in the past, I did run two instances, and found that it worked as expected. However, I did not test recent code in this situation.
patrakov
commented
1 year ago By re-reading the bug description, I arrived at the following impression: the root cause of the complaint is that fping is not being killed. mwan3 is irrelevant. I have already complained about this, see https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/135379/2245?u=patrakov - and that's why I am on the older version now.
patrakov
commented
1 year ago @Quba1 Please test version 1.2.0.
Quba1
commented
1 year ago @patrakov See #164
lynxthecat
commented
1 year ago @Quba1 please can you test the latest code in 'master' since I think the last few commits may have resolved the issue you identified.
Quba1
commented
1 year ago The latest push to the master has indeed resolved the issue. Thank you for your help.
lynxthecat
commented
1 year ago Yay!
Answering @lynxthecat from #161 about running
cake-autorateas a service with multi wan, there seems to be some inconsistencies.I just had following chain of events happen:
cake-autorateservice running correctlyservice cake-autorate stopcake-autoratebecame disabled and processes didn't stop (output ofps | grep -e bash -e fpingremained the same)cake-autorateprocesses disappearedcake-autorateservice, it started and worked correctly for both interfacescake-autorateservice started automatically, but this time secondary interface didn't logDATAservice cake-autorate stopcake-autorateprocesses stopped, and service didn't become disabled (just stopped)service cake-autorate startcake-autoratestarted but secondary instance still don't logDATAservice cake-autorate stop, all processes stopped, executedservice cake-autorate startand both interfaces are logging correctlyFor me, this behavior shows no logic, and I'm wondering is it
cake-autorateor my device.