Anyone using Raspbian Chromium to connect to Kiwi admin page? [fixed in v1.602]

edited May 15 in Problems Now Fixed

I have someone who connects to the admin page from the default browser of an RPi running Raspbian. We think this browser is Chromium (still checking).

What happens is that the Kiwi immediately crashes after the admin connection. And the kiwi.json configuration has become corrupted because the file is only half the size it should be (the second half of the data is chopped off). This doesn't happen when I connect over the Internet using the usual suspects (desktop Firefox, Chrome, Safari and Opera).

So we're wondering if this is a Chromium bug as the kiwi.json file is changed from javascript in the browser and written back to the Kiwi server using large web socket writes (that in itself may be the source of the problem).

Thank you.


  • I have a Rpi, but have never used it for KiwiSDR admin.

    I've figured out where kiwi.json is. Presumably if I make a copy of the file before trying this, I can delete the corrupted kiwi.json file & replace it with the copy I made, right?

    I'll have a go - soon would be a good time as it seems there's been more solar flatulence so can afford everything going down here - provided there's certainty of recovering & doing so quickly. Please confirm as soon as practical that the crash won't leave me unable to recover things by ssh. And what I need to do to get the Kiwi running again. Presumably "..the Kiwi immediately crashes.." implies the Beagle sails on through & ssh isn't dropped? I have no idea what I'm doing with this stuff, still.

    Chromium on my Rpi is v92.0.4515.98

    73, Brett.

  • jksjks
    edited May 9

    Yes. You can even copy a saved kiwi.json (e.g. kiwi.json.GOOD) into kiwi.json while the server is in its loop of starting and immediately crashing. Chances are good that when it finds the good file it will then recover.

    I'm almost certain now this is the problem. A careful reading of how web sockets actually work shows how badly they behave when buffering is scarce. The resource-constrained environment of the RPi is exactly why Chromium is used.

    Your ssh is safe because the kiwi server is being started (and crashing) in the background and has nothing to do with your terminal session. The restarting is automatic (every 20 or 30 seconds I believe).

    Thanks for checking this.

  • Mate, I must've done something wrong here.

    I ssh'd in to the Kiwi, made a copy of kiwi.json. Opened another tab on RPi Chromium (it's presenting 10m FT4 to JTDX next-release-on-test) & selected admin bookmark, ready for entry of password. Also had Kiwi admin already going on a W7P machine, as well as AnyDesk watching a headless Ubuntu desktop machine with 11 JTDX instances chewing on 4 Kiwi receivers presented by kiwiclientd so could see what was going on when I pulled the trigger by entering the password for admin on the Rpi.

    Entered the password, and.... nothing happened. Well, other than the getting into admin on the Rpi, where elapsed time for users on the status tab kept chugging away. Then checked GPS tab, all fine there, then back to status where everything was still motoring along. Was like nothing happened. Everything kept running. Hence I must've done something wrong...

    73, Brett.

  • jksjks
    edited May 10

    Not necessarily. The person who is having trouble might be using an old Chromium, old Raspbian or something else. He's 12 hours out-of-phase with me so our communication time is limited and I don't know these details yet (hence why I asked here). But thank you for the valuable data point. It helps a lot.

  • Problem sounsds familiar. Sometimes I had the admin page open on a PC and also a Rpi4 (version chromium same as in the second post) because they are at different locations and noticed that an error in kiwi.json prevented a restart. In these cases replacing kiwi.json with a saved version brought everything back to normal. Actually I found that the problematic file version almost had doubled in size and I will send an example of that to the support email.

    After restricting to using only one access event to the admin page I have not seen the problem again, but that is inconclusive of course. Siince locally we had a lot of power outages recently I attributed the kiwi.json file corruption to that.

    73, Ben

  • jksjks
    edited May 10

    @VR2BG The guy got back to me and he's running Chromium 72 + Debian 9. So much older than the Chromium 92 you tested with.

    But I've also got problems with my code now that I understand the poor handling of large write requests by web sockets. Maybe fixing the code will allow Chromium 72 to work.

    We've also had quite a number of cases over the years of seemingly random corruption of the kiwi.json file. We've never really had a good explanation for this, attributing it to filesystem corruption as a result of power failures etc. I'd feel a whole lot better if it's an actual bug that got fixed.

    @benson Having multiple admin connections open is problematic. I used to think it was only an issue if multiple connections were used to make simultaneous config changes (because you get write collisions on the config file). But now I think it's worse than that and I need to only allow a single open admin connection. Similar to how I now disallow an open admin connection when an operation requiring admin privileges is attempted in user mode (e.g. editing a dx label).

  • Perhaps related.... I run Linux and Chrome. Over the years I find that if I sit on the GPS Az/El page in Admin overnight, things lockup my system, not the Kiwi. I reported this a long time ago and agreed to not do that anymore since it hurts!

  • There's a lot of data flowing from the Kiwi to those animations on the admin GPS page. On the browser side the old status data is supposed to be garbage collected by javascript. But it's possible there's a missing de-reference that causes it to be held.

    That can be debugged, sort of, by using the memory tab in the console window. But that thing is difficult to use IMHO. It only takes these complicated snapshots (Maybe it's better now. I haven't used it in a few years). Anyway, not a priority given the current disasters!!

  • edited May 11

    All this reminds me of what a colleague taught me ~40 years ago - and I have yet to see it disproved, repealed, need for revision, etc:

    The First Rule of Software - It isn't bug-free until you stop using it.

    The Second Rule of Software - Refer to The First Rule.

    73, VR2BG.

Sign In or Register to comment.