ArchLinux, отваливается I2P

Что-то мне подсказывает, что юнит написан через жопу. ExecStop=kill -TERM $MAINPID уже намекает.

А запости куда-нибудь содержимое файла «/lib/systemd/system/i2prouter.service».

http://pastebin.com/HhxUsc5G. Сам ничего не писал и не менял, оно само.

Господа знают толк в извращениях, да. Зачем-то ещё враппер-супервизор прикрутили, хотя systemd само и есть супервизор. И лог пишут не в stderr, а в свой собственный файл. И пресловутый ExecStop=/usr/bin/kill.

Но дело, видимо, не в юните — у меня всё работает. Покажи лог («/opt/i2p/wrapper.log»).

wrapper.log: http://pastebin.com/uRtdxSJq. Прошу прощения за огромную простыню, решил весь запостить.

Понятно... Он жабу не может найти.

ls -l /lib/jvm, осталось ещё немного :]

Странно, стоит жаба, даже две.

ls -l /lib/jvm

итого 0
lrwxrwxrwx 1 root root  14 сен 23 13:54 default -> java-8-openjdk
lrwxrwxrwx 1 root root  18 сен 23 13:54 default-runtime -> java-8-openjdk/jre
drwxr-xr-x 3 root root  72 сен 16 00:02 java-7-openjdk
drwxr-xr-x 6 root root 144 сен 23 13:54 java-8-openjdk

Симлинки не все расставлены.

archlinux-java set java-8-openjdk, проверь, что в директории появился симлинк «java-default-runtime -> default» и можно запускать.

https://wiki.archlinux.org/index.php/Java#Fixing_the_default_Java_environment

unikum

Сейчас потестил — неа, не сработает (ни set, ни fix). Вручную: ln -s default /lib/jvm/java-default-runtime.

# archlinux-java fix

В логе он пытается использовать /usr/lib/jvm/java-default-runtime который недавно заменили на default и default-runtime

Баг-репорт нужен тогда.

Большое спасибо, работает!

недавно заменили

После таких замен, порой, перестаёт хотеться юзать рач :)

А, они путь сменили. Странно, нигде об этом не сказано. Напейсал на страничку пакета...

Да, а где, собственно, можно было узнать о том, что его «недавно заменили»?

Напейсал на страничку пакета

You need to replace «java-default-runtime» with «default-runtime» in value of wrapper.java.command.

Вообще это в переменной окружения JAVA_HOME хранится. Они ссылаются на какой-то /usr/bin/java-service-wrapper, которого вообще в системе нет.

Да, а где, собственно, можно было узнать о том, что его «недавно заменили»?

Вроде нигде. Самому догадываться по неработающей джаве.

java-service-wrapper ставится как зависимость из одноименного пакета, а путь до бинарника java там указан полный (внутри файла wrapper.conf, как я и написал), так что JAVA_HOME ни при чём.

Вроде нигде. Самому догадываться по неработающей джаве.

Okay.jpg

Просто НИКОГДА не используй из репозиториев ни саму Java, ни софт написанный на Java

Правильный способ установки Java: скачать с сайта Oracle, положить в /opt, в каком-нибудь системной файле (н-р в /etc/profile или в ~/.bashrc) прописать переменную окружения JAVA_HOME и добавить $JAVA_HOME/bin в PATH.

Правильный способ установки софта, написанного на Java: такой же. (и так же как с самой Java, очень часто нужно руками задавать $APPNAME_HOME и добавлять его в PATH)

Просто НИКОГДА не используй из репозиториев ни саму Java, ни софт написанный на Java

Почему?

Правильный подход в джаве - всё своё тащу с собой. Одна софтина - один каталог в /opt - одна запись в PATH - возможно один $APPNAME_HOME. Часть софта должна нести с собой свой собственный JRE или JDK (сейчас всё больше именно JDK, на мегабайтах больше не экономят).

Зависимости конечно есть, но они подтягиваются с помощью пакетного менеджера типа Maven или Sbt на этапе СБОРКИ софта. Когда уже всё собрано - это монолит «руками не трогать». Возможно, можно было бы сделать нормальный пакетный менеджер, учитывающий особенности Java - но этот пакетный менеджер должен был бы знать кучу систем сборки, и главное - работать в source-based дистрибутиве типа Gentoo. Бинарным дистрам этого не грозит вообще.

а упоротые дистрибутивщики пытаются совершить над этой системой надругательства. Распиливают дистрибутив жавы на кусочки. Устанавливают им какие-то свои чмоды (отчего JDK перестает работать). Кладут симлинки в «/bin». Распиливают джава-софт на кусочки и пытаются разложить его по линуксовым пакетам. Особо фимозные товарищи даже пытаются разложить эти кровавые кусочки по стандартным для сишных либ местам и назвать их соответственно. И потом поверх конечно нужно понаписать лапши на bash, которая будет двигать симлинки и хардлинки, чтобы эта куча говна не развалилась.

Это называется шизофрения. Она начинается с создания в вики статьи «организация пакетов для Java». Если такая статья есть (и она не состоит из одной строчки «не надо никак их организовывать, сваливайте в /opt») - то это всё, ку-ку, досвидос.

Не надо учить плохому, нормально всё из репозиториев ставится.

Врёшь анимешник! Только оракл, только правильное и сертифицированное ПО!

А на всяких ваших опен постоянно глюки.

УМВР, не разу не видел глюков специфичных для openjdk. В идее глюки интерфейса бывали, но я всегда их на всякий случай перепроверял с оракловской — точно так же воспроизводятся.

Опять врёшь, этак два года назад, был короткий период, когда Idea вообще не запускалась (починили). Я как раз тогда с переустановкой ОС хотел на open перейти ибо apt-get install openjdk-xxx проще, но с тех пор желания нет. С оракл надёжнее.

Насчёт двух лет назад не скажу, я тогда эклипсой пользовался. Но с конца 2012 ни одной проблемы не видел на openjdk-7, которая не повторялась бы на оракле.

OpenJDK сейчас отличается от Oracle JDK только отсутствием проприетарщины. А проприетарщина, в основном, связана с UI и графикой. Соответственно, на серверный и command-line софт переход на OpenJDK должен повлиять по мнинимуму.

этак два года назад,

два года назад openjdk был совершенно в другом состоянии

ну и еще, если хочешь - глянь код Идеи. Там жуткие костыли для UI понаписаны. Какие-то отдельные ошмётки для OSX, для винды, для линукса. Наверняка это никуда не делось. Как раз юзались хаки, специфичные для OracleJDK, а вот это должны были минимизировать.

Мне надо было бэкпортировать UI-фичу из свежей Идеи в Идею годичной давности - пришлось попотеть, и заодним утащить пару десятков новых классов (можно и не тащить - всё заведется, но интерфейс превратится в кашу. А так нафиг они не нужны.). Такшта Идея - то еще поделие =)

А как всякие апдейты? Или имеется ввиду, что в идеале в пакет входит всё сразу и апдейтится при сборке, а ты апдейтишь пакет, где всё вместе?

да, в идеале апдейтится при сборке

чтобы экономить время загрузки пакетов Maven делает так: он хранит все скачанные библиотеки в ~/.m2/repository (местоположение можно поменять в конфиге или параметром в командной строке). Но место на жестком диске сэкономить не получится, всё равно нужно докладывать/копировать все библиотеки прямо в саму софтину.

почему еще важно апдейтить при сборке. Это же вам не сишные софтины, которые апдейтятся подменой файлов. В джавовских системах сборки активно используются так называемые плагины, которые изменяют поведение сборщика неузнаваемо. Два разных пакета могут собираться вообще по разным принципам. Например, какая-то софтина может просто скачать зависимости и этим удовлетвориться, а другая софтина прямо в процессе сборки скачает груви и питон, нагенерит ими кода, скопилирует, этот код что-нибудь еще скачает, всё это десять раз перепакуется и переуплотнится. И для мавена огроооомные скрипты сборки - это нормально.

а тот джава софт, который не использует вообще никаких систем сборок - там обновление полностью на совести автора, наверное.