O openjdk-7-jdk depende do systemd?

4

Estou tentando instalar openjdk-7-jdkno Ubuntu Trusty (com aptou aptitude), mas parece depender systemd, o que eu gostaria de evitar. Mas também não consigo ver systemdna saída de debtreeor apt-rdepends. Por que? Será que openjdk-7-jdkdependem systemdou não?

Para lhe dar uma visão geral, estou provisionando um servidor. E tudo acontece durante a instalação elasticsearch. Quer javae javaquer systemd. Mas após a instalação systemd, ele não pode ser ativado elasticsearch, pois vem com o script init, não com o arquivo de unidade systemd. Ele vê systemctle supõe que deve ser usado, não service.

UPD Não precisa systemdaté que eu faça apt update. Antes apt update:

# apt-cache policy openjdk-7-jdk
openjdk-7-jdk:
  Installed: (none)
  Candidate: 7u101-2.6.6-0ubuntu0.14.04.1
  Version table:
     7u101-2.6.6-0ubuntu0.14.04.1 0
        500 http://archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
     7u51-2.4.6-1ubuntu4 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

# apt-cache policy systemd
systemd:
  Installed: (none)
  Candidate: (none)
  Version table:

Depois apt update:

# apt-cache policy openjdk-7-jdk
openjdk-7-jdk:
  Installed: (none)
  Candidate: 7u121-2.6.8-1ubuntu0.14.04.1
  Version table:
     7u121-2.6.8-1ubuntu0.14.04.1 0
        500 http://archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
     7u51-2.4.6-1ubuntu4 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

# apt-cache policy systemd
systemd:
  Installed: (none)
  Candidate: 204-5ubuntu20.20
  Version table:
     204-5ubuntu20.20 0
        500 http://archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages

Eles não estão mudando o Ubuntu Trusty systemd?

Além disso, o sistema operacional está sendo executado no contêiner lxc, mas duvido que isso tenha a ver com isso. E é uma instalação nova, por assim dizer. I criar recipiente, faça o login, apt update, apt install openjdk-7-jdk, e ele quer systemd.

/etc/apt/sources.list:

deb http://archive.ubuntu.com/ubuntu trusty main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu trusty-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu trusty-security main restricted universe multiverse

E nada dentro /etc/apt/sources.list.d.

apt systemd jdk openjdk aptitude x-yuri
fonte
Se você está provisionando um servidor, por que não provisioná-lo com o Ubuntu 16.04? Desde então systemd, isso resolveria o seu problema, além de ter uma vida útil de suporte mais longa que o Ubuntu 14.04 (Trusty).
Mark Stosberg
O software a ser executado no servidor ainda não foi atualizado para poder ser executado no Ubuntu mais recente. Por enquanto, decidimos continuar com o Ubuntu Trusty.
X-yuri

Respostas:

6

Existe um pacote de openjdk-7-jdk disponível para o Ubuntu 14.04 (Trusty) . 14.04 é baseado no Upstart, não confiável. Portanto, o pacote deve executar 14.04 sem o sistema systemd init.

O pacote systemd a que você se refere é systemd a partir de atualizações confiáveis . Nessa página, você pode baixar e revisar os pacotes que o Debian adicionou para compor o pacote.

No arquivo compactado, você encontrará isso no arquivo README:

O systemd pode ser instalado juntamente com o sysvinit e não altera o comportamento do sistema imediatamente. Isso é intencional. Para testar o systemd, adicione:

init=/bin/systemd

na linha de comando do kernel e, em seguida, reinicie ou instale o pacote systemd-sysv.

O systemd fornece vários pacotes, dos quais o OpenJDK deve depender de um. Você pode confirmar que o systemd-sysvpacote não é uma dependência.

Não estou ciente de nenhuma circunstância em que a instalação de pacotes padrão no Ubuntu 14.04 resultaria na mudança do sistema para usar systemd como o sistema init sem que o usuário explicitamente o ativasse.

Se o seu sistema 14.04 de alguma forma terminar com o Upstart e o systemd instalados, você pode interromper o processo de inicialização, entrar no menu grub e modificar a linha de comando do kernel para adicioná init=/sbin/upstart-lo à inicialização com o Upstart e, em seguida, desinstalar ou alterar o que for necessário.

Para resolver o problema do elasticsearch não iniciar, use http://packages.ubuntu.com para encontrar uma versão do elasticsearch a partir de trustyou anterior e copie o script "init.d" de lá. Essa correção persistirá por meio de atualizações da pesquisa elástica que você pode fazer.

Eu acho que você está em um estado estranho, porque mesmo usando o 14.04, alguns mantenedores de pacotes estão esperando systemd. Não acho que você encontre uma solução melhor do que a solução alternativa assim.

Mark Stosberg
fonte
Sinta-se à vontade para fazer perguntas sobre o meu ambiente. E confira minha pergunta, por favor, adicionei mais detalhes.
X-yuri
Aqui você vai, systemdno trusty-updates.
X-yuri
Resposta atualizada.
Mark Stosberg
11
You can confirm that the systemd-sysv package is not a dependency.Eu vejo a única maneira (se o systemd-sysv ainda não estiver instalado): apt install openjdk-7-jdke veja se ele deseja instalá-lo. Como eu disse anteriormente, não consegui encontrar a cadeia de dependência que leva ao pacote systemd. Você pode ajudar aqui? Então, não estou dizendo que meu sistema mudou para systemd. Estou dizendo que depois de instalar o openjdk-7-jdk o ansible vê / bin / systemctl e tenta usá-lo para ativar a pesquisa elástica. Mas o elasticsearch não vem com o arquivo de unidade systemd. Ele vem com o script init. E ansible falha.
X-yuri
Resposta atualizada para lidar com falha de elasticsearch.
Mark Stosberg
1

Acabou systemdsendo retirado como uma recomendação, a saber:

http://packages.ubuntu.com/trusty-updates/openjdk-7-jdk
http://packages.ubuntu.com/trusty-updates/openjdk-7-jre
http://packages.ubuntu.com/trusty- updates / libgtk-3-0
http://packages.ubuntu.com/trusty/libcolord1 (recomenda colord)
http://packages.ubuntu.com/trusty/colord
http://packages.ubuntu.com/trusty-updates / policykit-1
http://packages.ubuntu.com/trusty-updates/libpam-systemd
http://packages.ubuntu.com/trusty-updates/systemd-services

E aqui podemos ver a diferença de comportamento entre contêineres LXC e servidores físicos. Os contêineres LXC geralmente vêm com um conjunto básico de pacotes. Coisas como estas pode estar faltando: man, less, ping, vi, curl.

O ponto é que systemd-servicesdepende systemdou systemd-shim(> = 3). Após uma nova instalação do Ubuntu, você normalmente systemd-shiminstala. Portanto, a instalação openjdk-7-jdknão puxa o systemdpacote.

No caso do contêiner LXC, nenhum desses dois está instalado; portanto, ao solicitar apta instalação, openjdk-7-jdkele escolhe o primeiro: systemdpacote.

Uma maneira de combatê-lo é instalar systemd-shimantes de instalar openjdk-7-jdk. O que eu mais gosto, já que o outro ( apt install --no-install-recommends openjdk-7-jdk) pode rejeitar algumas dependências úteis.

Veja esta discussão na lista de discussão para obter mais detalhes.

Consulte esta pergunta para obter detalhes sobre o rastreamento de dependências.

x-yuri
fonte