4

I'm trying to install openjdk-7-jdk on Ubuntu Trusty (with apt or aptitude), but it seems to depend on systemd, which I'd like to avoid. But also, I can't see systemd in the output of debtree or apt-rdepends. Why is that so? Does openjdk-7-jdk depend on systemd or not?

To give you the bigger picture, I'm provisioning a server. And it all happens when installing elasticsearch. It wants java, and java wants systemd. But after installing systemd, it can't enable elasticsearch, since it comes with init script, not systemd unit file. It sees systemctl and supposes it's to be used, not service.

UPD It doesn't need systemd until I do apt update. Before 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:

After 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

Aren't they switching Ubuntu Trusty to systemd?

Also, the OS is running in lxc container, but I doubt that has to do with this. And it's a fresh install, so to say. I create container, log in, apt update, apt install openjdk-7-jdk, and it wants 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

And nothing in /etc/apt/sources.list.d.

x-yuri
  • 581
  • 2
  • 7
  • 19
  • If you are provisioning a server, why not provision it with Ubuntu 16.04? Since it has systemd, that would solve your problem as well has having a longer support lifespan remaining than Ubuntu 14.04 (Trusty). – Mark Stosberg Dec 30 '16 at 15:27
  • The software to be run on the server is yet to be updated to be able to run on newer Ubuntu. For now we decided to stick with Ubuntu Trusty. – x-yuri Dec 30 '16 at 17:09

2 Answers2

6

There is a package of openjdk-7-jdk available for Ubuntu 14.04 (Trusty). 14.04 is based on Upstart, not trusty. Therefore, the package must run 14.04 without the systemd init system.

The systemd package you referring to is systemd from trusty-updates. From that page, you can download and review the packages that Debian added to make the package.

In compressed archive, you'll find this in the README file:

systemd can be installed alongside sysvinit and will not change the behaviour of the system out of the box. This is intentional. To test systemd, add:

init=/bin/systemd

to the kernel command line and then rebooting, or install the systemd-sysv package.

systemd provides a number of packages, of which OpenJDK must depend on one. You can confirm that the systemd-sysv package is not a dependency.

I'm aware of no circumstance in which installing standard packages on Ubuntu 14.04 would result in switching the system to use systemd as the init system without the user explicitly opting in.

Should your 14.04 system somehow end up with both Upstart and systemd installed, you can interrupt the boot process, enter the grub menu and modify the kernel command line to add init=/sbin/upstart to boot it back with Upstart, and then uninstall or change what you need to.

To solve the problem with elasticsearch not starting, use http://packages.ubuntu.com to find a version of elasticsearch from trusty or earlier, and copy the "init.d" script from there. This fix will persist through upgrades of elasticsearch that you may do.

I think you are caught an odd state because even though you are using 14.04, some package maintainers are moving to expect systemd. I don't think you're going to find a better fix than the workaround like that.

muru
  • 197,895
  • 55
  • 485
  • 740
Mark Stosberg
  • 3,327
  • Feel free to ask questions about my environment. And check out my question please, I've added more details. – x-yuri Dec 30 '16 at 17:17
  • Here you go, systemd in trusty-updates. – x-yuri Dec 30 '16 at 17:22
  • Answer updated. – Mark Stosberg Dec 31 '16 at 11:24
  • 1
    You can confirm that the systemd-sysv package is not a dependency. I see the only way (if systemd-sysv is not installed yet): apt install openjdk-7-jdk and see if it wants to install it. As I said earlier, I failed to find the dependency chain that leads to systemd package. Can you help here? Then, I'm not saying that my system switched to systemd. I'm saying that after installing openjdk-7-jdk ansible sees /bin/systemctl and tries to use it to enable elasticsearch. But elasticsearch doesn't come with systemd unit file. It comes with init script. And ansible fails. – x-yuri Dec 31 '16 at 12:32
  • Answer updated to deal with failing elasticsearch. – Mark Stosberg Dec 31 '16 at 17:47
  • If Ansible is using the presence of /bin/systemctl to decide that it's on a systemd based system, that's a bug, since systemctl can be installed on Ubuntu 14.04 when systemd is not the init system. Here are better ways to detect the init system in use – Mark Stosberg Jan 03 '17 at 19:46
  • See also Can I see why a package is installed? to review the dependencies. – Mark Stosberg Jan 03 '17 at 19:48
  • @MakrStosberg I didn't look into finding a way to detect init system. But if you did, you can take a look at what ansible does and file a report, if you care. Although it doesn't seem there's a fullproof way. Also, this is how I managed to trace back the dependency. And, I seem to have found a workaround: install systemd-shim beforehand, see my answer. – x-yuri Jan 05 '17 at 01:31
1

It turned out, systemd was pulled in as a recommendation, namely:

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 (recommends 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

And here we can see the difference in behavior between LXC containers and physical servers. LXC containers usually come with basic set of packages. Things like these might be missing: man, less, ping, vi, curl.

The point being, systemd-services depends on systemd or systemd-shim (>= 3). After fresh Ubuntu install you usually have systemd-shim installed. So installing openjdk-7-jdk doesn't pull in systemd package.

In case of LXC container, neither of those two is installed, so when asking apt to install openjdk-7-jdk it choses the first one: systemd package.

One way to fight it is install systemd-shim before installing openjdk-7-jdk. Which I like more, since the other one (apt install --no-install-recommends openjdk-7-jdk) might reject some useful dependencies.

See this mailing list discussion for more details.

See this question for details on tracing back dependencies.

Community
  • 1
x-yuri
  • 581
  • 2
  • 7
  • 19