Wekan Snap on CentOS 7, RHEL7 and Fedora 31 does not upgrade properly #103
Comments
|
What does these commands output? Please anonymize logs before adding as comment. |
|
I'm seeing exactly this, too. Wekan was working fine on Friday, and now (Monday morning) it doesn't. I'd not stopped the service or rebooted; this is a headless server we leave running continuously. sudo snap list: sudo snap logs wekan.wekan: sudo snap logs wekan.mongodb: |
|
Is Wekan running? I think you could install all updates with apt or yum, and reboot. I have not had any problems with updating Snap. |
|
Anyway, with only this kind of logs I can't debug more. As always, keep daily backups: If there is any problems, reinstall Wekan, save settings, remove and reinstall Wekan: And then restore from your daily backup. |
|
You're asking me a question and then immediately closing the ticket and saying you can't help any more? Gee, thanks. ::slow handclap:: |
|
You can always add comment to issues. I do open and close issues based on feedback, is there any problems after instructions I gave to fix it. |
|
That |
|
I do also have problems sometimes explaining myself. With reply like |
|
You've not given me any instructions to fix the issue. "Just reinstall the software from scratch" is not something I ever want to hear for a live system, especially when -- as it seems here -- you don't actually know it will fix the problem. If the logs aren't giving you enough information to debug the problem, perhaps you should ask the developer to output more useful logs? Oh wait, that's you. |
|
Please add to this issue comment output of these commands: |
|
sudo snap refresh sudo snap services |
|
Please add to this issue comment output of these commands: |
|
|
As your own user instead of user:user, please save this log to textfile, anonymize it's content, and include as attachment to this issue comment: |
|
I can't see anything in this that needs anonymising; feel free to correct me. I've had to truncate quite a bit (no such thing as an "attachment" here): |
|
Please add as comment output of the commands: There should be text like this, if Wekan works: If not, please add as comment anonymised output of this command: |
Oh, I see. hang on. |
|
Please try: |
|
Please try: |
|
Okay, that doesn't appear to have helped. |
|
Please add as comment anonymised output of this command: |
|
|
In that same directory /root, as root please try: Does it work then? |
|
Yes, it works fine if I delete everything and reinstall it. But we've already covered this. Going forward we're not going to be using a tool here if the only fix you can offer is to delete everything and reinstall it, and I really, really doubt that I'm the only one. We won't be using wekan any longer. |
|
This could very well be related how Snap works, or how CentOS work. I have not needed to do these kinds of reinstalls on Ubuntu or Debian, automatic upgrade has always worked for me. It would be very welcome to get even some ideas how to fix this, or what logs would help with this. I do rely on feedback at GitHub issues to improve Wekan. I'm also just a human, I do make mistakes, and try to correct those where possible. |
|
I have maintained Wekan since 2016-12, added many features and fixes, and it has required countless of hours to keep Wekan working as Snap package. Wekan is community driven Open Source project. If anyone at Wekan community has ideas how to debug this, or where I could look for more information, it would be very welcome. |
|
The problem above is about cultural differences in language. Wekan is very advanced product, similar ones are very expensive. To be able to fix some bug, I would need some way to duplicate it, or some error log somewhere where to even find a clue what is wrong. CentOS, Snap etc systems has a lot of code. Wekan itself also has a lot of code and dependencies, frameworks, databases, etc, most of them not written by me. Yes, I'm developing Wekan, but I really don't know everything about everything. |
|
I've posted a comment in the forum topic: https://forum.snapcraft.io/t/on-centos-7-snap-package-upgrades-do-not-work-properly-using-wekan-snap/14941/2 TLDR: mongodb fails to start with exit code 48, meaning:
Perhaps there's another process already listening on that port,
|
|
I am also reporting the same situation as @andy-twosticks. It was working on Friday then off on Monday, no issue prior to this since install, has been installed for about a month, RHEL7. |
|
@westonganger do you see the same log from mongo in the journal? Can you try identify if there's another process already occupying the port or why otherwise mongo fails by using the commands I posted above? |
xet7
changed the title
|
|
I think Snap can not access /tmp. Snap can only access directories below I'll check what is the current default setting for this, maybe it is wrong. |
|
Oops sorry, please don't try above. I'll try to find correct working setting. |
|
It seems when I changed socket setting to something, my local Wekan install stopped working. This made it work again: |
|
Socket is set here: Default seems to be empty string: For Snap, currently I'm using MongoDB 3.2.22: I would really like to upgrade to newest MongoDB 4.x, but I have problems getting it working: I'll try to figure it out. Help would be very welcome. |
A snap has a private |
|
@westonganger Just for the record, Also, if you haven't removed the snap, can you try to open a shell inside the snap namespace and check whether |
|
That looks fine then. Is That doesn't explain ENOENT though. Only explanation I see is that when this happens, |
|
@westonganger just to be clear, this started happening after the wekan snap got updated, not the |
No snapd was not updated. |
|
@westonganger can you revert the snap to a previous revision? |
xet7
changed the title
This was referenced Jan 9, 2020
|
Until CentOS 7 and RHEL7 is fixed, it's possible to move to some newest Ubuntu or Debian where updates work: |
|
Snap currently uses Ubuntu 16.04 version of MongoDB. There is this: So would this mean, that for CentOS 7 I would need to also include CentOS 7 version of MongoDB ? |
This was referenced Jan 11, 2020
|
Currently problem is just with Snap. If someone would like to use Wekan on CentOS 7 or RHEL7, it's also possible to use Docker. |
|
im also have this problem. I just wanted copy database and move to another server. But when im trying start snap wekan.mongodb start - its started for a 10-15 seconds. Then its crashes. This why i cant do mongodump --port 27019 - its says: |
xet7
changed the title
|
Moved to wekan/wekan#5562 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I don't know if some snap update has this effect, anyway I am unable to use wekan anymore,
I get in the logs:
Sep 2 15:21:04 www2 mongod.27019[5652]: [initandlisten] MongoDB starting : pid=5652 port=27019 dbpath=/var/snap/wekan/common 64-bit host=www2.in.at.spe.net
Sep 2 15:21:04 www2 mongod.27019[5652]: [initandlisten] db version v3.2.22
Sep 2 15:21:04 www2 mongod.27019[5652]: [initandlisten] git version: 105acca0d443f9a47c1a5bd608fd7133840a58dd
Sep 2 15:21:04 www2 mongod.27019[5652]: [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
Sep 2 15:21:04 www2 mongod.27019[5652]: [initandlisten] allocator: tcmalloc
Sep 2 15:21:04 www2 mongod.27019[5652]: [initandlisten] modules: none
Sep 2 15:21:04 www2 mongod.27019[5652]: [initandlisten] build environment:
Sep 2 15:21:04 www2 mongod.27019[5652]: [initandlisten] distmod: ubuntu1604
Sep 2 15:21:04 www2 mongod.27019[5652]: [initandlisten] distarch: x86_64
Sep 2 15:21:04 www2 mongod.27019[5652]: [initandlisten] target_arch: x86_64
Sep 2 15:21:05 www2 mongod.27019[5652]: [initandlisten] options: { net: { bindIp: "127.0.0.1", port: 27019 }, storage: { dbPath: "/var/snap/wekan/common", journal: { enabled: true }, mmapv1: { smallFiles: true } }, systemLog: { destination: "syslog" } }
Sep 2 15:21:05 www2 mongod.27019[5652]: [initandlisten] listen(): bind() failed errno:2 No such file or directory for socket: /tmp/mongodb-27019.sock
Sep 2 15:21:05 www2 mongod.27019[5652]: [initandlisten] Failed to set up sockets during startup.
Sep 2 15:21:05 www2 mongod.27019[5652]: [initandlisten] dbexit: rc: 48
What can I do?
Thanks
Paolo
The text was updated successfully, but these errors were encountered: