Unable to enable apps after upgrading to 6.11.1 #33140
Comments
Please fill out a bug template. We can't help you without it. |
|
Given that the bug template contains a section "Steps to reproduce": how exactly does one, on a clean instance, reproduce an app being grandfathered? |
Most likely you can't..... quite probably the devs can, or will know why this occurs. Steps to reproduce (which is the information I was after) will likely be:
But that may be hard to reproduce with old apps that are no longer available. |
|
@paulchen Can you run your setup using |
|
Hi! I'm having the same problem. I updated the server from <6.10 to 6.11 directly without updating to 6.10. |
Please fill out a bug template with your server details and your update history. Which version did you upgrade from? It may be the same issue, and it may not. |
|
I did. :) Is there a way to get the actual update history of the rocketchat server? |
Why on earth did you open a duplicate issue? All you had to do was put the server info here so we could see that you were using the same setup. Like this: Version 6.11.1 Starter license 1 instance
Only via your logs as far as I remember. |
|
Sorry, I'm new to this. I used the link above for the template as you said fill out the template. |
@reetp I updated my initial comment to include the sections that I initially left out.
@tapiarafael I ran my setup with that environment variable. I added the log output to the initial comment.
@Mal0815 This is in fact possibly related. Your log contains the error However, my current "problem" is that after a reboot of the server running Docker, the apps work as expected and I do not experience the problem reported in this issue anymore. Please be aware that due to various professional and private obligations, my replies to comments in this issue might be severely delayed in the next few weeks. |
|
Good morning! by running systemctl edit rocketchat.service for my deployment on debian. Is this correct? |
|
Same here with Jitsi. https://forums.rocket.chat/t/jitsi-no-more-availabe-after-update-to-version-6-12-0/20524 |
|
This issue has been marked as stale because there has been no further activity in the last 10 days. If the issue remains stale for the next 4 days (a total of 14 days with no activity), then it will be assumed that the question has been resolved and the issue will be automatically closed. |
github-actions
bot
added
the
stat: no response
I think so.
The issue still persists. Today, I updated my setup to Rocket.Chat 6.12.1. |
github-actions
bot
removed
the
stat: no response
Yep |
|
This issue has been marked as stale because there has been no further activity in the last 10 days. If the issue remains stale for the next 4 days (a total of 14 days with no activity), then it will be assumed that the question has been resolved and the issue will be automatically closed. |
github-actions
bot
added
the
stat: no response
The issue still persists. No Rocket.Chat update was released in the meantime. The fact that I have to write a comment in this thread every two weeks because there is no activity by the Rocket.Chat team is slightly annoying. |
|
Rocket is a big org and paid customers come first. If you have a paid subscription you can contact support directly. Otherwise, as you know, it is open source. YMMV. There are no guarantees. I know devs have been putting in hours on v7 which is their focus right now. Doesn't help. Also difficult to reproduce so hard to debug. |
|
If the Rocket team cannot get to this issue within ten days, they should turn off the bot. |
This. Just to be clear, I don't expect anything to happen within any timeframe. I'm also fine with closing issues that have been waiting for input from the reporter for a long time. However, I don't see any point in generating two comments in this issue every two weeks just to make sure it doesn't get closed. |
|
Regrettably a large number of issues are just left and not closed by the OPs even if they have a solution, or possibly fixed but not tagged. Hence umpteen thousand open issues, most of which in reality could be closed. This is an exception to the rule. Note. When I worked at Rocket we did take the bot off, which is fine if managed continuously. But I left, and again, no one in the community steps up to help. If the community isn't bothered to help? 🤷♂️ You reap what you sow. I do what I can, as and when I can. Currently trying to relax with a glass of wine on the sofa after a long day :-) The dev did respond, but without being able to recreate this it will be difficult, and I'd imagine the short answer might be to remove apps and install fresh versions to see if it clears it. You did that on the test vm and it worked? |
github-actions
bot
removed
the
stat: no response
I just tried that once more, to no avail. This error showed up:
From the logs: |
|
This issue has been marked as stale because there has been no further activity in the last 10 days. If the issue remains stale for the next 4 days (a total of 14 days with no activity), then it will be assumed that the question has been resolved and the issue will be automatically closed. |
github-actions
bot
added
the
stat: no response
|
Did you try updating deno on RC 7.0.0? For me it didnt work until I updated to version |
|
@amsnek Yes, I did run Airgapped is our requirement too, and we'd prefer deno to be bundled with RC directly. We download apps using an online instance and then upload those apps as private apps into airgapped ones. |
|
@Gummikavalier ah, I build and package an RPM for an rhel8 install -> similiar to TAR install I suppose. I use rc-apps deploy to install locally. |
|
Deno - see here. I have asked that all the docs be updated.
https://docs.rocket.chat/docs/deploy-with-ubuntu For airgapped please see this: |
|
@Mal0815 can you try downgrading Deno to 1.37.1? |
|
Hi! I did the downgrade: Now, I can successfully install a new app. Giphy works, too! Great step forward. :) Edit: Thank you very much! :))) Edit: |
|
That's great! So apparently the version of Deno that installations must get should be exactly 1.37.1? Let's see if this solves the problems for others as well |
|
Unfortunately, my Docker-based setup still doesn't work as expected. I managed to get both GIPHY and Tenor running by executing these steps:
However, after restarting the container once more, I once more get the "Timeout: app process not ready" error message. I tried reapplying the above steps once more, but now the apps won't at all. When installing them, I get the "Timeout: app process not ready" error. The situation is basically the same as initially reported. I'll give it a try whether I can replicate this in a separate Docker Compose setup like in #33140 (comment). However, this might take some time as I have a lot of other stuff to do.
These are the most recent versions. |
|
Hey @paulchen, that's really weird for a Docker deployment to not be able to start the process, as we package the very version of Deno we used for development with Rocket.Chat. One thing that crosses my mind is the possibility that the server isn't able to retrieve the actual zip package from where it is stored. By default this is configured to be the database, which shouldn't pose any problems when switching to docker deployment, but if you happen to have changed that previously the container might not be able to access the files after restart. |
|
There is good info here and I'm sure I'll get deno working alright if I download it from deno.land site and set it up that way. But I also understood that deno runtime is packaged with RC 7.0.0 tar but just needs compiling with correct commands and path variable in place. I'm still puzzled why if I follow this instruction with RHEL8, and I assume this is the way it should be done from now on with RHEL based tar installs: With above I get end result: But when I compile RC 7.0.0 (and any other previous versions of RC by far) works ok but does not seem to compile deno: So I'm just puzzled now whether the new apps-engine path for starting compiling works for RHEL8 at all. |
|
https://docs.rocket.chat/docs/deploy-with-centos does seem to be missing the Deno installation instructions, I'll check with the team.
Not exactly, what we do is package the dependencies used by the deno program that serves as the runtime, but the executable itself needs to be installed in the host system. Also note, as we seem to have found above, it seems that Deno should be on version 1.37.1 to properly work with the dependencies (detail to be updated in the docs).
This step should not be taken for 7.0. There was a change in the internals of the apps-engine, that's why you're seeing the "Unsupported URL Type "workspace:": workspace:~" error. |
|
Hi again. FYI: I'll stick with 1.37.1 Bye. :) |
|
@d-gubert Thanks for clarifying these out. Appreciated! 🤗 |
I used the above docker-compose.yml file, but immediately started with Rocket.Chat 7.0.0.
I don't know what's going on. However, I have a suspicion: My local machine is not under load, my server is. So my question: May the problem simply be that nothing is broken, but something is simply taking too long? When installing an application fails, the log looks like this: At 20:40:36.090, the subprocess for the app is started. At 20:40:46.110 (about 10s later), the "Timeout: app process not ready" error occurs. At 20:41:04.959, the subprocess sends a message about being ready (which is too late). However, when installing the app succeeds (which happens every now and then), the logs look like this: At 20:41:19.933, the subprocess for the app is started. At 20:41:20.040, the subprocess is ready. Subsequently, additional methods can be called. However, I have no idea on how to deal with this. |
|
I had now time to study my RHEL8 + TAR case more. Got it working. To find deno binary I had used |
Apparently deno is now required to run some apps from the marketplace (like jitsi) https://docs.rocket.chat/docs/deploy-with-ubuntu#install-deno It has to be exactly version 1.37.1 as per RocketChat/Rocket.Chat#33140
|
This issue has been marked as stale because there has been no further activity in the last 10 days. If the issue remains stale for the next 4 days (a total of 14 days with no activity), then it will be assumed that the question has been resolved and the issue will be automatically closed. |
github-actions
bot
added
the
stat: no response
|
The issue persists, I'm now on 7.1.0. |
github-actions
bot
removed
the
stat: no response
Reminder sent. |
reetp
added
Tasked
|
Got this working with It would be great if the instructions at https://docs.rocket.chat/docs/deploy-with-centos (and others if applicable) were updated because my road to get here was quite rocky (pun intended), particularly with the following:
|
|
First note right at the top of the page it says:
That's it. Otherwise YMMV.
In the doc there is a link to the deno guide: "Install Deno: Only Deno versions >=1.37.1 and <2.0.0 are supported.
See: "Additional steps for installing 6.10 release" (Should probably say 6.10+) Eg
Not everyone may want too... You can add notes to docs where it says "Was this article helpful?" Unless you follow the recommended deployment methods you may face issues. Also note it always helps to read all the docs for all the deployment methods. |
Yes, but if you are going to supply a page to support CentOS, then it should be maintained as well.
Fair enough. That was my mistake.
This was not sufficient. I had to export PATH=/home/rocketchat/.cache/deno/bin:$PATH as well to make it run otherwise it would not find the deno binary to compile the apps when you try to install them.
I appreciate the time taken for the response though. I'll submit a request to improve the article through the feedback link. |
|
I did say quite clearly their docs tell you: "The recommended deployment methods are Docker, AWS, and Kubernetes.
Unfortunately it doesn't work like that.... They could just as easily pull it as it isn't a supported install..... They have slowly deprecated unsupported stuff over time. They maintain as and when on a " best effort" basis... It is what it is. (note I don't work here so don't shoot the messenger!!)
Cool. Please also post your notes on open.rocket.chat - you'll find me there - and I'll try and push the team to get it updated (There is a lot of stuff out of date) |
I apologize if I came across harsh. I was at the peak of frustration with the install. I do appreciate that there being any documentation at all, I would have been more lost if there had been none. Happy holidays. |
On my server, something similar to #32761 reappeared some days ago. However, I'm running a Docker installation instead of a manual setup.
Description:
The apps GIPHY and Tenor have been installed for a long time on my instance (they're grandfathered). Since a few days, both of them are disabled and can't be enabled.
When trying to enable them, an error message is shown:
See below for the error log.
Steps to reproduce:
Expected behavior:
The app is now enabled.
Actual behavior:
An error message is shown:
Server Setup Information:
Client Setup Information
Additional context
On a test instance, only Tenor was installed. I am unable to enable Tenor, but I was able to make GIPHY running.
On the same test instance, I uninstalled Tenor, but now I'm unable to reinstall it. When trying it, another error message is shown:
Error log:
On 2024-08-31 around 21:30, I rebooted the server running Docker. Afterwards, Giphy and Tenor started working on both Rocket.Chat instances. See below for the logs.
Relevant logs
Nothing is logged on client side.
Contents of the log file on server side:
As suggested in one of the comments, I fired up the server with the environment variable,
DEBUG=appsEngine:runtime:*:Both apps were not enabled, but they were periodically pinged with success.
After the reboot at 2024-08-31 around 21:30, there were a lot more log entries:
The text was updated successfully, but these errors were encountered: