TWCManager as a service, sysv_ipc.ExistentialError: The queue no longer exists

[mattiasclaesson]

Running TWCCManager as a service on a RPI. Seems like it throws a exception after I log off the session? Tested again to make the fault happen. but this time it did not...

master.getModuleByName("WebIPCControl").processIPC() File "/home/pi/TWCManager/lib/TWCManager/Control/WebIPCControl.py", line 99, in processIPC webMsgRaw = self.webIPCqueue.receive(False, 2) sysv_ipc.ExistentialError: The queue no longer exists Traceback (most recent call last): File "/home/pi/TWCManager/TWCManager.py", line 539, in master.getModuleByName("WebIPCControl").processIPC() File "/home/pi/TWCManager/lib/TWCManager/Control/WebIPCControl.py", line 99, in processIPC webMsgRaw = self.webIPCqueue.receive(False, 2) sysv_ipc.ExistentialError: The queue no longer exists

A service restart fixes the issue.

[MikeBishop]

@ngardiner, this is for communicating with the legacy Web UI on port 80, isn't it? Is it time to just get rid of the legacy UI anyway?

[ngardiner]

Yes, I agree on both counts.

The quick workaround for this is to remove the following line:

    "Control.WebIPCControl",

From the modules_available list at the top of TWCManager.py. I think the next step is to just disable this module by default, but I have recently come across a reason not to remove it outright - it seems a project (openWB) uses that legacy webui in an interesting way (by calling the old chargeNow function) to integrate with TWCManager, and as a result removing it entirely would break that integration.

But defaulting it to off is no big deal IMHO, and if it's off, I'll make sure it doesn't create the IPC queue so this sort of error doesn't happen. It is a breaking change for some users, so I'll make sure there's some doco around it.

[ngardiner]

Just a follow up, this is done already. I think it's time the old interface was retired by default. This was merged in 2d11155.

I've updated the doco to reflect what needs to be done to enable the functionality for those who need it, and I've added a link to the legacy web UI itself pointing to the doco, so most people will be informed of the change if they do use the UI.

[MikeBishop]

I have recently come across a reason not to remove it outright - it seems a project (openWB) uses that legacy webui in an interesting way (by calling the old chargeNow function) to integrate with TWCManager, and as a result removing it entirely would break that integration.

Hm, given that they're grepping the HTML for data as well, it seems like the HTTP API would be appealing to them. Though I suppose they're wanting to support the original TWCManager fork as well. Ideally, someone who uses both could send a PR to them splitting this TWCManager off as a separate interface type, if we have anyone who knows their codebase well enough to do that easily.

[Der-Kieler]

openWB has a Forum where bugs and features are discussed (german language). "LutzB" is one of the programmers there, I think. So he is perhaps the right person to discuss it. I'm sorry that I can't help, because I'm far away from understanding the work which is needed. :-/

https://openwb.de/forum/viewforum.php?f=5 https://openwb.de/forum/viewforum.php?f=9

[Flitzer42]

I am one of the users (not developers) of OpenWB (in combination with TWCManager). My observation: When setting TWCManager service to start automatically at system start with:

sudo cp twcmanager.service /etc/systemd/system/twcmanager.service
sudo systemctl enable twcmanager.service

and (re-) start the system with sudo reboot it fails with the above mentioned error after some hours.

When starting the service manually with sudo systemctl start twcmanager.service it works perfect (at least for several days).

This might help to narrow down the issue…. or to find a workround to get it stable without investing to much effort.

[ngardiner]

Hi @Flitzer42, this should have been patched already in v1.2.1 from the commit 2d11155 on Jan 7. Could you please test for us if the problem has gone away after a reboot when on v1.2.2? Commands to ensure you're on the latest code are:

git pull
git checkout main

If you see no errors, all should be good. If you do get an error from the above commands please let me know.

[Flitzer42]

Hi @ngardiner thanks for updating. The content of "WebIPCControl.py" has changed after the update (and is now identical to what is highlighted in the linked commit from January). Thought I did it before in the same way when swithing to 1.2.2 .... . Nevertheless, it runs now after the update and I will observe it. It will take a while to make sure that it is working stable for longer period... In the past it crashed after some hours... First observations:

1. Web UI reports "We experienced an error trying to save your settings. This means that while your current settings will be retained for the current session, they will not be saved if TWCManager exits. Please check the permissions on /etc/twcmanager/settings.json and try saving your settings again."
2. Settings for "spike" disapeared from "debug" settigns page

[Flitzer42]

First results are not promising: System get stuck after a few hours Journalctl reports:

Apr 28 20:39:19 raspberrypi python3[521]: 19:39:19 TWCManager 20 Unhandled Exception:Traceback (most recent call last): Apr 28 20:39:19 raspberrypi python3[521]: File "/home/pi/TWCManager/TWCManager.py", line 624, in Apr 28 20:39:19 raspberrypi python3[521]: master.getModuleByName("WebIPCControl").processIPC() Apr 28 20:39:19 raspberrypi python3[521]: File "/home/pi/TWCManager/lib/TWCManager/Control/WebIPCControl.py", line 112, in processIPC Apr 28 20:39:19 raspberrypi python3[521]: webMsgRaw = self.webIPCqueue.receive(False, 2) Apr 28 20:39:19 raspberrypi python3[521]: sysv_ipc.ExistentialError: The queue no longer exists I charged the car and unplugged after charge complete. I do not know whether this has something todo with the issue. I do not know wheter this happened at the same time or not. Edit 2021-05-01 After a reboot it now runs for 3 days stable, will further observe...

[ngardiner]

Hi @Flitzer42,

Could you please let me know if this is in your config.json:

    "control": {
        "IPC": {
          "enabled": true
        },

Just as some background - the IPC interface is the old web interface. It uses IPC pipes to communicate between TWCManager and the Web UI, and that's what you are seeing above - an attempt to read the queue. For some time now, we have disabled the IPC interface by default. The line causing this error shouldn't be reached if your config doesn't have IPC enabled as we check first whether the module is loaded before we try to run the processIPC function.

If IPC is disabled which is the default setting, you should not see this error.

[ngardiner]

Sorry, I just made the connection between this issue and the other issue - you're using openWB and therefore need the legacy interface enabled to allow integration between it and TWCManager. In this case, the error you see is expected. In almost every other case you would not need the module enabled and you wouldn't see the error.

Lets keep this issue open, but it's really an unfortunate situation in that the easy solution is to get rid of the legacy UI which we're entirely ready to do now that the new interface supports all of the features the legacy interface did (except for some minor debug features but they are nearly implemented already), however we're keeping the legacy interface around expressly because we have openWB users who rely on it. Fixing this issue may be possible for the IPC interface but there's very little reason to invest in maintaining it further as it's not really an optimal way of doing things.

What I am tempted to do instead is to cut free the legacy UI completely and add a backwards compatibility parsing of the old interface's non scheduled charging endpoint to allow openWB to continue to work but this will still need development work - I will just leave this here for the moment until we have time to consider it further.

[Flitzer42]

Hi @ngardiner Thanks for the reply. As the feature is deprecated I do not expect / request any improvement or bugsfix. Just keep it as is for now. After updating to your latest version (checkout main) it seems to work more stable (at least now for 6 days). So for now, I am happy!