Gadget common error 500

Dashboard error gadget.common.error.500

after all the updates on the way from JIRA V6.1 to JIRA V8.4 I got an error on the dashboard of the activity stream gadget » gadget.common.error.500″.

Also this error I found in error.log:

2019-09-11 09:00:58,224 http-nio-8080-exec-11 ERROR jira_admin 540x632x2 1jmz0yk /plugins/servlet/gadgets/makeRequest [c.a.g.r.internal.http.HttpClientFetcher] Unable to perform a request to: https:// /jira_neu/rest/webResources/1.0/resources

SSL certificate is signed and imported correctly in Apache.

Whats going wrong here?

2 answers

1 accepted

Sorry to hear you are facing a problem.

Per the description of your error, it seems that you are being impacted by the problem mentioned in the article below:

basically, an invalid or absence of a certificate can lead to such errors. Could you please double-check if you are using the correct certificate? Also, check if the correct baseUrl is set in the System -> General Configuration.

If that’s not the problem, I checked another customer facing the same problem after configuring direct SSL with self-signed certificates in JIRA 8.0.1 tomcat. As you can see in this thread, he managed to fix it by adding his self-signed ca and server certificates to tomcats JRE Keystore:

keytool -importkeystore -destkeystore cacerts -srckeystore /opt/certs/servkeystore.p12 -srcstoretype pkcs12 -alias tomcat -deststorepass changeit -srcstorepass -validity 3650
keytool -importkeystore -destkeystore cacerts -srckeystore /opt/certs/keystore.p12 -srcstoretype pkcs12 -alias ca -deststorepass changeit -srcstorepass -validity 3650

Let me know if those suggestions work for you.

Источник

gadget.common.error.500 using nginx and HTTPS

Hello, I recently installed Jira 8.2.0 on a RHEL8 server and I’m with issues about gadgets on System Dashboard.

It appears to be an widespread problem:

I gone through all those topics and tried everything, even mimicking configurations, but I wasn’t able to solve this issue by myself.

So I’m here for help.

Here’s my configurations:

I tried adding the web certificates to the keystore located on /opt/atlassian/jira/jre/lib/security/cacerts and it doesn’t solved the issue too.

And yes, my base URL is set to: https://jira.domain.tld.

Thanks for your help.

4 answers

1 accepted

I solved this changing the JRE to the system JRE instead of the shipped JRE. Everything worked flawlessly after the change.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

I did not understand the change you made. Do you have any step-by-step instructions?

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

I have exactly the same config and problem. Has anyone managed to solve it? I’m using F5 to avoid loading the certificate into the Jira application.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

Hi! I have exactly the same config and problem.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

@Polybio FernandesDid the guide solve your problem? After upgrading I am having the same issue. 🙁 Other than that, Jira does work flawless. Just having that gadget URL error.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

This may be because the update has replaced the «server.xml» file for the default settings.

Mine resolved as follows:

For SSH, enter the / opt / atlassian / jira / conf folder
# vi server.xml

1) Comment all jira configuration block DEFAULT:

2) Enable the HTTPS block settings as example remembering to enter the domain name of your certificate that is in F5 in the «proxy name».

If you’re proxying traffic to Jira over HTTPS, uncomment the below connector and comment out the others.
Ensure the proxyName and proxyPort are updated with the appropriate information if necessary as per the docs.

See the following for more information:

«
maxThreads=»150″ minSpareThreads=»25″ connectionTimeout=»20000″ enableLookups=»false»
maxHttpHeaderSize=»8192″ protocol=»HTTP/1.1″ useBodyEncodingForURI=»true» redirectPort=»8443″
acceptCount=»100″ disableUploadTimeout=»true» bindOnInit=»true» secure=»true» scheme=»https»
proxyName=»jira.domain.com» proxyPort=»443″/>

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

Источник

gadget.common.error.500 LAN DNS no https

Just launched self-hosted Jira instance. Get gadget.common.error.500 on the project summary page when I access the site from via the DNS route I set up, but not when I use the virtual machine IP address.

Setup (ips changed for security reasons):

VM Ubuntu 18.02-LTS Server with .bin installation of Jira/Confluence (10.0.0.2 for example)

VM Windows Server 2016 running DNS Server (10.0.0.3 for example).

—DNS ResourceRecordA -name jira.company.local -IPv4Address 10.0.0.2

In Jira, set baseURL to jira.company.local or jira.company.local:8080 and access via browser address (see note, jira.company.local port forward not working)

-Site works fine besides the gadget problem.

In Jira, set baseURL to 10.0.0.2 or 10.0.0.2:8080 and access via browser address (see note, jira.company.local port forward not working)

-Site works fine besides the gadget problem.

*Temporarily solving problem:

In Jira, set baseURL to 10.0.0.2 or 10.0.0.2:8080 and access via browser address (see note, 10.0.0.2 80 to 8080 port forward not working)

**Couple problems also arise

Port forwarding in the Tomcat server doesn’t seem to be working. I must create shortcuts for LAN users using :8080 port (Jira) or :8090 (Confluence). Maybe I need to set explicit traffic redirection in Ubuntu?

When accessing via jira.company.local, some features don’t work (adding comment gives stream error)

https has NOT been enabled yet while testing. No certificate present.

1 answer

1 accepted

Since you do not have a port forwarding and there is no proxy or web server in front of your JIRA and Confluence application servers, the best way is to set up base URL for JIRA as,

This way the incoming requests will hit your application server on the respective port (i.e 8080). I understand with this in place, the site works fine besides the gadget problem. You may have to now conquer the issues with gadgets. Check the logs and see what errors are throwing with respect to gadgets.

Do the application links set up correctly and working between JIRA / Confluence? Please see below link for further help.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

I think, since the gadgets use a REST API, we just need to enable reverse lookups on company.local and the gadgets should work.

Confluence would not talk to Jira or vice versa via lookup using LAN IP addresses or fqdn. They are hosted on the same VM, though (so same IP). What did work was localhost:8080, localhost:8090 (127.0.0.1:8080 and 127.0.0.1:8090).

We have multiple intranet web applications. We’ll examine a few options.

One, I think, is having windows server portproxy all traffic to jira.company.local:80 to jira.company.local:8080 and confluence.company.local:8090. Not super excited about that as windows portproxy doesn’t have an allowupdate parameter, but that’s ok. Should be static for our use case.

Another is adjusting IP tables in the ubuntu VM hosting the application:

But, then I can’t host both applications on the same VM. This is Ok. but I really don’t want to deal with two databases for effectively the same package. So we’ll need spin up ANOTHER container to run postgresql. I’m hoping I can figure out portproxy or create some kind of inner redirect.

Источник

gadget.common.error.500

I am runing Jira out of a docker container on my Synology NAS.

The NAS uses an SSL certificate from Let’s Encrypt.

In the System Dashboard Gadgets are not shown, instead there is a

I read about importing the certificate somehow but I only have basic Linux knowledge. Is there a fix for this?

1 answer

1 accepted

I would run through https://confluence.atlassian.com/jirakb/gadgets-failing-to-load-in-jira-server-behind-a-proxy-218276785.html just to check that it is SSL related and not one of the other possible causes of that error.

For what it’s worth, I can tell you that Letsencrypt certificates can work fine, I run some Atlassian stuff at home with them. My usual trick is forgetting to import the client certificate into the jvm keystore on upgrade (System information page does not list that as a changed file, otherwise I’d remember)

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

thanks for your hint.

In the jira logs I could confirm an SSL error.

I could import the unsigned certificate of my NAS.

After a restart of the docker container the gadgets now work fine.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

Источник

gadget.common.error.500

I installed Jira 8 on a Ubunt 18.04, using a lighttpd reverse proxy to offer https to clients.

On the dashboard I get a «gadget.common.error.500»

Th error in catalina.out seems to be the cause:
14-Feb-2019 08:33:52.483 WARNING [http-nio-8080-exec-9] com.sun.jersey.spi.container.servlet.WebComponent.filterFormParameters A servlet request, to the URI https://es.hinlocal.ch/rest/activity-stream/1.0/preferences?_=1550133232310, contains form parameters in the request body but the request body has been consumed by the servlet or a servlet filter accessing the request parameters. Only resource methods using @FormParam will work as expected. Resource methods consuming the request body by other means will not work as expected.

How do i fix this?

4 answers

I had this problem after configuring direct SSL with self-signed certificates in JIRA 8.0.1 tomcat. In main board i was getting gadget.common.error.500 error message.

After few hours i have managed to solve it by adding my self-signed ca and server certificates to tomcats jre keystore:

keytool -importkeystore -destkeystore cacerts -srckeystore /opt/certs/servkeystore.p12 -srcstoretype pkcs12 -alias tomcat -deststorepass changeit -srcstorepass -validity 3650
keytool -importkeystore -destkeystore cacerts -srckeystore /opt/certs/keystore.p12 -srcstoretype pkcs12 -alias ca -deststorepass changeit -srcstorepass -validity 3650

BTW Confluence 6.14 does not have this problem and works without this configuration.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

Have not tried this out but makes sense, thanks!

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

Just hit the same issue and the certificate import solved it for me as well. Thank you

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

It’s not working for me. I’m putting the certificates on cacerts of embedded JRE from Jira located in /opt/atlassian/jira/jre/lib/security/cacerts.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

Do you see imported certificates in keystore:

keytool -list -keystore /opt/atlassian/confluence/jre/lib/security/cacerts

Do you see whole chain of these certificates (root, intermediate, server) in keystore?

For self signed certs to work with updated browsers there must be at least root and branch server cert, encryption algorithm must be at least SHA256, and in server certificate Subject Alternate Names there must have FQDN of the server.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

Yes, I can see the certificate:

]# keytool -list -keystore /opt/atlassian/jira/jre/lib/security/cacerts | grep jira

Enter keystore password: changeit

jira , May 24, 2019, PrivateKeyEntry,

I don’t have root CA or intermediate, since it’s a self-signed one. Generated following the Atlassian SSL guide: https://confluence.atlassian.com/jira/connecting-to-ssl-services-117455.html

I tried everything that you could imagine. I don’t know what to do anymore. Struggling for 2 complete days with it.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

We had the same issue, using a GoDadddy signed certificate. And the solution above worked. It was important to make sure that we had a PKCS12 keystore which we then added to the cacerts in our case:

the command identical to Mindaugas

From memory it was important to have the PKCS12 (.pfx) as nothing else would work.

As it’s a wild card certificate which works for all out sub domains: *.domain.tld, I think even at one point I exported it from a Windows IIS server which created a nice little .pfx file which was easily imported using the above command into cacerts.

Also had a brief look at your config, don’t have time at the moment to look in great detail, but this my connector in server.xml from the machine where we ran the above command to fix the error.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

Quick question I tried to do the fix with the CAcerts and I replaced the original one inside the /security folder with the one that has my domain cacerts will that affect jira and if so does anyone know how to recover or get a copy of the original cacerts

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

Just wanted to add some more info in case anyone else came across a similar situation. In my case, there’s a few specific configurations that are important.

— Jira is running in a docker container using AWS ECS and a load balancer with path based routing

— SSL is terminated at the load balancer

— The load balancer has a DNS alias atlassian.my.domain.com

— The environment variable ATL_PROXY_NAME is set to match the alias above

— The certificate is entered into the trust store via a command like the following (where $ is the DNS name of the load balancer);

Источник

I use JIRA in a cloud infrastructure where it’s obviously desirable to serve the contents over SSL, therefore I set up an NGINX as a JIRA reverse proxy for unencrypted requests to the JIRA backend service and handle the SSL on the front end with Let’s Encrypt. We need to let JIRA know that we are proxying it over HTTPS however by setting some values in server.xml first.

Notice that my Let’s Encrypt SSL certificates are in the /etc/letsencrypt/live/jira.doublesharp.com directory, but yours will be specific to the hostname you create them for. The certs are created via the letsencrypt command and use Nginx to process the validation request. Once created the generated PEM files can be used in your Nginx config. Note that you will need to comment out this line in the SSL config if they don’t yet exist, start Nginx to create the certs, uncomment the lines to enable SSL, and then restart Nginx once again (whew!).

JIRA Reverse Proxy Configuration

Configure JIRA to add proxyName, proxyPort, scheme, and secure parameters to the Tomcat Connector in server.xml.

<Connector port="8081" 
           maxThreads="150" 
           minSpareThreads="25" 
           connectionTimeout="20000" 
           enableLookups="false" 
           maxHttpHeaderSize="8192" 
           protocol="HTTP/1.1" 
           useBodyEncodingForURI="true" 
           redirectPort="8443" 
           acceptCount="100" 
           disableUploadTimeout="true" 
           bindOnInit="false" 
                    
           proxyName="jira.doublesharp.com" 
           proxyPort="443" 
           scheme="https" 
           secure="true" 
/>

Don’t forget to copy the database driver to $JIRA_INSTALL/lib.

Nginx Reverse Proxy Configuration

Note use of “jira.doublesharp.com” in config and change as needed. This configuration uses a subdomain specific certificate from Let’s Encrypt, but you could also use a Wildcard Certificate for your JIRA reverse proxy setup as well which can help to consolidate your key generation.

# Upstream JIRA server on port 8081. Use 127.0.0.1 and not localhost to force IPv4.
upstream jira {
  server       127.0.0.1:8081 fail_timeout=0;
}

# listen on HTTP2/SSL
server {
  listen       443 ssl http2;
  server_name  jira.doublesharp.com;

  # ssl certs from letsencrypt
  ssl_certificate /etc/letsencrypt/live/jira.doublesharp.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/jira.doublesharp.com/privkey.pem;

  location / {
    # allow uploads up to 10MB
    client_max_body_size 10m;
    # set proxy headers for cloudflare/jira
    proxy_set_header  Host $host:$server_port;
    proxy_set_header  X-Real-IP $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    # hand the request off to jira on non-ssl
    proxy_pass        http://jira;
  }
}

# redirect HTTP and handle let's encrypt requests
server {
  listen       80;
  server_name  jira.doublesharp.com;
  root         /var/lib/jira;
  
  # handle letsencrypt domain validation
  location ~ /.well-known {
    allow all;
  }

  # send everything else to HTTPS
  location / {
    return 302 https://jira.doublesharp.com;
  }
}

В статье мы расскажем, как исправить ошибку (код состояния) 500 со стороны пользователя и администратора сайта, а также подробно разберём, что такое ошибка запроса 500.

Что такое внутренняя ошибка сервера 500

Код ошибки 5хх говорит о том, что браузер отправил запрос корректно, но сервер не смог его обработать. Что значит ошибка 500? Это проблема сервера, причину которой он не может распознать.

Сообщение об ошибке сопровождается описанием. Самые популярные варианты:

• Внутренняя ошибка сервера 500,
• Ошибка 500 Internal Server Error,
• Временная ошибка (500),
• Внутренняя ошибка сервера,
• 500 ошибка сервера,
• Внутренняя ошибка HTTP 500,
• Произошла непредвиденная ошибка,
• Ошибка 500,
• HTTP status 500 internal server error (перевод ― HTTP статус 500 внутренняя ошибка сервера).

Дизайн и описание ошибки 500 может быть любым, так как каждый владелец сайта может создать свою версию страницы. Например, так выглядит страница с ошибкой на REG.RU:

Как ошибка 500 влияет на SEO-продвижение

Для продвижения сайта в поисковых системах используются поисковые роботы. Они сканируют страницы сайта, проверяя их доступность. Если страница работает корректно, роботы анализируют её содержимое. После этого формируются поисковые запросы, по которым можно найти ресурс в поиске.

Когда поисковый робот сканирует страницу с ошибкой 500, он не изменяет её статус в течение суток. В течение этого времени администратор может исправить ошибку. Если робот перейдёт на страницу и снова столкнётся с ошибкой, он исключит эту страницу из поисковой выдачи.

Проверить, осталась ли страница на прежних позициях, можно с помощью Google Search Console. Если робот исключил страницу из поисковой выдачи, её можно добавить снова.

Код ошибки 500: причины

Если сервер вернул ошибку 500, это могло случиться из-за настроек на web-хостинге или проблем с кодом сайта. Самые распространённые причины:

• ошибки в файле .htaccess,
• неподходящая версия PHP,
• некорректные права на файлы и каталоги,
• большое количество запущенных процессов,
• большие скрипты,
• несовместимые или устаревшие плагины.

Решить проблему с сервером можно только на стороне владельца веб-ресурса. Однако пользователь тоже может выполнить несколько действий, чтобы продолжить работу на сайте.

Что делать, если вы пользователь

Если на определённом ресурсе часто возникает ошибка 500, вы можете связаться с владельцем сайта по инструкции.

Перезагрузите страницу

Удаленный сервер возвращает ошибку не только из-за серьёзных проблем на сервере. Иногда 500 ошибка сервера может быть вызвана небольшими перегрузками сайта.

Чтобы устранить ошибку, перезагрузите страницу с помощью сочетания клавиш:

• на ПК — F5,
• на ноутбуке — Fn + F5,
• на устройствах от Apple — Cmd + R.

Обратите внимание! Если вы приобретаете товары в интернет-магазине и при оформлении заказа появляется 500 Internal Server Error (перевод — внутренняя ошибка сервера), при перезагрузке страницы может создаться несколько заказов. Поэтому сначала проверьте, оформился ли ваш предыдущий заказ. Если нет, попробуйте оформить заказ заново.

Очистите кэш и cookies браузера

Кэш и cookies сохраняют данные посещаемых сайтов и данные аутентификаций, чтобы в будущем загружать веб-ресурсы быстрее. Если на ресурсе уже был статус ошибки 500, при повторном входе на сайт может загружаться старая версия страницы с ошибкой из кэша, хотя на самом деле страница уже работает. Очистить кэш и куки браузера вам поможет инструкция.

Если ни одно из этих действий не решило проблему, значит, некорректно работает сам сервер сайта. Вернитесь на страницу позже, как только владелец решит проблему.

Что делать, если вы владелец сайта

В большинстве случаев устранить проблему может только владелец сайта. Как правило, ошибка связана с проблемами в коде. Реже проблемы могут быть на физическом сервере хостинг-провайдера.

Ниже рассмотрим самые популярные причины и способы решения.

Ошибки в файле .htaccess

Неверные правила в файле .htaccess — частая причина возникновения ошибки. Чтобы это проверить, найдите .htaccess в файлах сайта и переименуйте его (например, в test). Так директивы, прописанные в файле, не повлияют на работу сервера. Если сайт заработал, переименуйте файл обратно в .htaccess и найдите ошибку в директивах. Если вы самостоятельно вносили изменения в .htaccess, закомментируйте новые строки и проверьте доступность сайта.Также может помочь замена текущего файла .htaccess на стандартный в зависимости от CMS.

Найти директиву с ошибкой можно с помощью онлайн-тестировщика. Введите содержимое .htaccess и ссылку на сайт, начиная с https://. Затем нажмите Test:

Произошла непредвиденная ошибка

На экране появится отчёт. Если в .htaccess есть ошибки, они будут выделены красным цветом:

500 ошибка nginx

Активирована устаревшая версия PHP

Устаревшие версии PHP не получают обновления безопасности, работают медленнее и могут вызывать проблемы с плагинами и скриптами. Возможно, для работы вашего веб-ресурса нужна более новая версия PHP. Попробуйте сменить версию PHP на другую по инструкции.

Установлены некорректные права на файлы и каталоги сайта

В большинстве случаев корректными правами для каталогов являются «755», для файлов — «644». Проверьте, правильно ли они установлены, и при необходимости измените права на файлы и папки.

Запущено максимальное количество процессов

На тарифах виртуального хостинга REG.RU установлены ограничения на количество одновременно запущенных процессов. Например, на тарифах линейки «Эконом» установлено ограничение в 18 одновременно запущенных процессов, на тарифах «+Мощность» ― 48 процессов. Если лимит превышен, новый процесс не запускается и возникает системная ошибка 500.

Такое большое число одновременных процессов может складываться из CRON-заданий, частых подключений с помощью почтовых клиентов по протоколу IMAP, подключения по FTP или других процессов.

Чтобы проверить количество процессов, подключитесь по SSH. Выполните команду:

ps aux | grep [u]1234567 |wc -l

Вместо u1234567 укажите ваш логин хостинга: Как узнать логин хостинга.

Чтобы посмотреть, какие процессы запущены, введите команду:

Вместо u1234567 укажите логин услуги хостинга.

Командная строка отобразит запущенные процессы:

Код ошибки 500

Где:

• u1234567 — логин услуги хостинга,
• 40522 — PID процесса,
• S — приоритет процесса,
• /usr/libexec/sftp-server — название процесса.

Процесс можно завершить командой kill, например:

Вместо 40522 укажите PID процесса.

Чтобы решить проблему, вы также можете:

• увеличить интервал запуска заданий CRON,
• ограничить количество IMAP-соединений в настройках почтового клиента. Подробнее в статье Ограничение IMAP-соединений,
• проанализировать запущенные процессы самостоятельно или обратившись за помощью к разработчикам сайта.

Если вам не удалось самостоятельно устранить ошибку 500, обратитесь в техподдержку.

Скрипты работают слишком медленно

На каждом виртуальном хостинге есть ограничения на время выполнения скрипта. Если за установленное время скрипт не успевает выполниться, возникает ошибка сервера 500. Для решения проблемы обратитесь к разработчику сайта и оптимизируйте скрипты. Если оптимизировать нельзя, перейдите на более мощный вид сервера.

У пользователей VPS есть возможность увеличить максимальное использование оперативной памяти на процесс, но лучше делать скрипты меньшего размера.

Ошибка 500 на сайте, созданном на WordPress

WordPress предлагает много плагинов для создания хорошего сайта. Они значительно расширяют возможности CMS. Однако они же могут нарушать работу сайта и вызывать ошибку 500. Вызвать ошибку могут как недавно установленные плагины, так и старые.

Для начала проверьте, нужно ли обновить плагины. Часто устаревшие плагины перестают работать и вызывают проблемы работы сайта. Если все плагины обновлены, но 500 Internal Server Error остаётся, отключите все плагины, чтобы убедиться, что именно они мешают работе сайта. Как только станет понятно, что виноват один из плагинов, отключайте их по очереди, пока не найдёте тот, который нарушает работу сервера.

Если все ваши действия не решили проблему или вы не уверены в своих технических знаниях, обратитесь к службе технической поддержки. Сообщите время обнаружения проблемы и опишите все действия, которые вы предприняли перед обращением. Специалисты сделают детальную проверку настроек вашего сайта и при необходимости обратятся к администраторам сервера на стороне хостинг-провайдера.