Как Hudson работает автономно в Linux? - PullRequest
1 голос
/ 21 октября 2010

Мне нужно знать механизмы и порядок запуска Хадсона, чтобы я мог понять, в чем дело. Когда вы набираете

nohup java -jar $HUDSON_WAR > $HUDSON_LOG 2>&1 &

(конечно, используя реальные значения для этих переменных), что именно происходит? Я работаю разработчиком программного обеспечения более 10 лет, но в основном во встраиваемых системах, и веб-сервисы находятся вне моего домена. Я не думаю, что это имеет значение, но я использую Hudson на RHEL 5. Он не использует tomcat или apache; он работает как автономный сервис. Какие файлы доступны и почему?

Вот особенности ошибки: я скачал плагин, и после того, как он закончил загрузку, я остановил, а затем перезапустил Hudson, как я делал это много раз раньше. На этот раз, однако, когда я пытаюсь получить доступ к главной странице Hudson, я получаю

Error 404
Exception:
Stacktrace:
 (none)

Я подозревал проблему с разрешениями, так как заметил, что некоторые вещи в HUDSON_HOME принадлежат root, поэтому я рекурсивно chown и chgrp'd этот каталог, чтобы все это принадлежало hudson. Это не решило проблему. Я попытался восстановить предыдущий hudson.war, но получил то же самое поведение. Одна вещь, которую я заметил, это то, что сразу после того, как я запускаю ее, если я захожу на веб-страницу, я вижу страницу «запуска» Хадсона, а затем она переключается на ошибку 404. Я попытался запустить Хадсон с другим номером порта и получил такое же поведение У меня нет проблем с доступом к веб-интерфейсу управления исходным кодом на том же сервере.

Обновление: я все еще подозреваю проблему с разрешениями. Возможно, последний, кто перезапустил Hudson, сделал это от имени root.

Update[2]: Excerpt from hudson.log:
[Winstone 2010/10/21 16:05:17] - Beginning extraction from war file
hudson home directory: /home/hudson
[Winstone 2010/10/21 16:05:17] - HTTP Listener started: port=8080
[Winstone 2010/10/21 16:05:17] - AJP13 Listener started: port=8009
Using one-time self-signed certificate
[Winstone 2010/10/21 16:05:17] - Error starting listener instance
java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:44)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:516)
    at winstone.Launcher.spawnListener(Launcher.java:232)
    at winstone.Launcher.<init>(Launcher.java:205)
    at winstone.Launcher.main(Launcher.java:391)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:600)
    at Main.main(Main.java:200)
Caused by: java.lang.NoClassDefFoundError: sun.security.x509.CertAndKeyGen
    at winstone.ssl.HttpsListener.<init>(HttpsListener.java:111)
    ... 12 more
Caused by: java.lang.ClassNotFoundException: sun.security.x509.CertAndKeyGen
    at java.lang.ClassNotFoundException.<init>(ClassNotFoundException.java:77)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:385)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:653)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:619)
    ... 13 more

Ответы [ 4 ]

2 голосов
/ 21 октября 2010

Я просто догадываюсь здесь, но вы, возможно, не используете правильный двоичный файл Java.

Часто в Linux двоичный файл Java в /usr/bin представляет собой реализацию Java gcc или пакет OpenJDK. В прошлом у меня были проблемы с этими пакетами Java, которые работали недостаточно хорошо. Если у вас установлен Oracle JDK Sun , он, вероятно, находится в /usr/java. Я предлагаю установить JAVA_HOME на /usr/java/default и убедиться, что при запуске Hudson запускается правильная среда выполнения Java.

export JAVA_HOME=/usr/java/default
nohup $JAVA_HOME/bin/java -jar $HUDSON_WAR > $HUDSON_LOG 2>&1 &

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

sudo /etc/init.d/hudson start

Кроме того, проверьте HUDSON_LOG и / или /var/log/hudson/hudson.log на наличие ошибок. Если это проблема с плагином, который вы недавно установили, вы можете отключить плагин, отодвинув в сторону папку [plugin] и файл [plugin].hpi в HUDSON_HOME/plugins

1 голос
/ 21 октября 2010

Кажется, что устранение неполадок Hudson обычно выполняется через интерфейс Manage Hudson с использованием скрипта Groovy. Кроме того, ведение журнала отладки, скорее всего, доступно. Цитата со страницы «Как добавить регистраторы»: «Скажите нам симптом вашей проблемы в списке пользователей, и мы сможем рассказать вам, куда вам нужно обратить внимание. Кроме того, это действительно просто оболочка вокруг Java. Пакет util.logging, поэтому, если вы программируете на Java, вы можете догадаться, на что смотреть ». Список пользователей, о котором они говорят, это список рассылки.

Как добавить новые / другие регистраторы : http://wiki.hudson -ci.org / display / HUDSON / Logging
Как попасть в список пользователей : http://wiki.hudson -ci.org / display / HUDSON / Mailing + List
Подробности администрирования : http://wiki.hudson -ci.org / display / HUDSON / Администрирование + Hudson
Сценарии : http://wiki.hudson -ci.org / display / HUDSON / Hudson + Script + Console
Еще несколько примеров сценариев : http://community.jboss.org/wiki/HudsonHowToDebug

0 голосов
/ 26 марта 2014

Я столкнулся с той же проблемой после обновления с jdk 7 до jdk 8 и установки glassfish 4 на том же сервере.Я решил эту проблему, переключившись обратно на прежний jdk:

альтернативы sudo --config java

Есть 3 программы, которые предоставляют 'java'.

Команда выбора

  • 1 /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java
  • 2 / usr / java / latest / bin / java 3 / var / lib / jenkins/tools/hudson.model.JDK/jdk7.45/bin/java

Введите, чтобы сохранить текущий выбор [+], или введите номер выбора: 3

0 голосов
/ 22 октября 2010

В конечном итоге эта проблема была вызвана двумя причинами: 1) Разрешения были перепутаны. Поскольку Hudson ранее был запущен как root, некоторые файлы, необходимые для работы, стали собственностью root. Я не смог найти хороший краткий обзор того, какие файлы, связанные с hudson, должны принадлежать hudson, а какие не могут работать в качестве пользователя root и предположений, поэтому после создания резервной копии я переустановил Hudson.

2) Поскольку я использовал дом Хадсона по умолчанию «.hudson» с точкой, но попытался перезапустить с указанным HUDSON_HOME / home / hudson (без точки), Хадсон создал новый дом в / home / hudson и действовал, как будто это была новая установка. Я где-то видел переменную HUDSON_HOME и подумал, что было бы хорошо указать ее в моем скрипте запуска как / home / hudson, и тем самым невольно изменил дом, используемый Хадсоном. Как только это будет исправлено, оно вернется к норме.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...