Hello,
Sure, I have already created ticket for this.
Thanks!
Hello,
Sure, I have already created ticket for this.
Thanks!
Hey @jonathan-g - this doesn’t appear to be reproducing anymore, so it might have been a temporary error on Zapier’s side.
Would you be open to trying again if it still occurs for you?
Hi @ShakaZzzz, have you had a chance to take a look at our troubleshooting tips: https://docs.mattermost.com/integrations/jira.html#why-doesn-t-my-jira-webhook-post-any-messages?
Hi @egoitzr and no worries!
You can share this improvement idea on our Feature Request forum: https://mattermost.uservoice.com/forums/306457-general. Thanks!
Hi, @gubbins
Thanks for the clarification. Since the server is identical (including the mattermost.service file too), I recommend you to run the following command to reload systemd manager configuration:
systemctl daemon-reload
systemctl restart mattermost.service
Once done, try to reproduce the issue again.
Hey @adanial,
I already did the daemon-reload
a few times while adding the stop timeout. It didn’t make any difference.
I guess the most obvious difference between the main and test servers is that the main server has hundreds of client sessions connecting, including some bots, while the test server has typically only one client session (i.e. me testing stuff).
Is there not some kind of thread / activity dump I can grab while in the hung state? Would that help to see what’s happening?
I don’t know dbus internals, but the applications you are describing (telegram and dropbox) are using qt and python respectively with their own notification/systray implementation. Would you mind testing another electron based application to see whether the culprit is (again!) the electron framework?
Would you mind testing with github-desktop for example? This is a good electron candidate using the systray.
Note: please note on Arch Linux, github desktop is using node-lts-carbon which might break some other packages needing node > 10.
The problem was indeed the WAF module of the F5 sitting in front of the server. The websocket profile was missing there, so websocket requests got resettet instantly. Strangely it worked for quite a while and did so every now and then for some time but that’s the business of the networking people.
You can increase the log level to print debug messages using these config settings, and add in the SQL trace to see if there’s a query that’s hanging the shutdown sequence.
Sound like it’s an opportunity for developers. let me know if you need content write.
No, that’s what I first suspected but wasn’t the cause in the end.
I guess I have to go over the config line-by-line and see what section is the issue. Is there anything that’s OS dependent in there?
Hi there! We have some Mattermost server, and noticed that any member (not system admin or team admin, just member) can manage members in the any channel. How we can fix this and allow to manage members only for system admins / team admins?
v1.0.4 of the jira plugin got releases today. Would you please check if this fixes your issue?
Hi @parikshit,
What Mattermost server version are you using?
What Gitlab version are you using?
Can you help read through this earlier thread to see if it helps you resolved the issue: Impossible to log-in using v4/api?
Hi @0xSheff,
Are you referring to the “Manage Members” link in the Main Menu or the “Manage Members” link below the Channel Members list in each channel?
@cpanato Do you know if this seems to be a bug and I should create a Jira ticket?
@amy.blais yes please create a jira ticket
thanks for reporting this, we will check that internally now
Opened a ticket here: https://mattermost.atlassian.net/browse/MM-13659.