Bug #4105
closedrc.update_bogons.sh fetch failure should never sleep on FW upgrade
0%
Description
This kills the whole upgrade process, since this gets stuck on sleep "forever" (one day at least, or even a week or month depending on what's configured on a particular system), unless you manage to connect via SSH and kill both the sh process and the sleep process and let things continue with package reinstall etc... :-(
Updated by Chris Buechler over 10 years ago
- Status changed from New to Feedback
- Priority changed from High to Normal
The bogon update sleep doesn't lock anything or prevent anything else from happening, it just sits in the background and waits. Anything else that needs to happen is not interrupted in any fashion. It certainly won't sleep for weeks or months, it can't, that's just a random 24 hour offset. What specifically was it preventing from happening for you?
Updated by Kill Bill over 10 years ago
Well, sadly this does not happen in the background... No idea why it does not background, as said the upgrade could not continue until the two processes were killed.
Updated by Chris Buechler over 10 years ago
- Target version deleted (
2.2)
still not seeing any way that sleep can hold up anything. Do you have specific steps to replicate?
Updated by Kill Bill over 10 years ago
Chris Buechler wrote:
still not seeing any way that sleep can hold up anything. Do you have specific steps to replicate?
CF card died on an Alix. Got a new one, reimaged with latest 2.2.2 snapshot, restored config, reboot. After the insane timeout due to pfBlockerNG aliases not resolving (another bug, please do something about it already) I got to the bogons thing. Sure enough, stuck there. SSH in, kill the fetch process, did not help. Kill the rc.update_bogons.sh, still not solved. Kill the sleep process and boot resumed.
Argh!
Updated by Kill Bill over 10 years ago
Hmm... so I discovered this in config.xml:
<shellcmd>/etc/rc.update_bogons.sh 0</shellcmd>
No idea how it got there?!
Updated by Chris Buechler over 10 years ago
Kill Bill wrote:
No idea how it got there?!
Guessing you put it there? Base code never touches shellcmd tags other than to execute them, and I'm not aware of any packages or anything else that'll automatically add anything there.
Don't think that would be related to what you described though, having any argument there means it skips sleep, so that one should have just quickly run and been finished.
Updated by Chris Buechler over 9 years ago
- Status changed from Feedback to Not a Bug
- Affected Version deleted (
2.1.2)
subject issue doesn't exist, user-added <shellcmd> responsible