How do services work in Ubuntu 16.04?

[SRGOM]

No description provided.

[fpqc]

All services in Ubuntu 16.04 are either directly run through systemd or using the systemd-sysvcompat extension (which launches classic-style initscripts/services using virtual units). Arch and Fedora use an all-systemd configuration, and I believe that Ubuntu 17.04 moves further in that direction. Socket-activated services will fail badly, while persistent daemons can be launched manually using a classic double-fork-off script.

[fpqc]

Systemctl does not work right now, because the systemd pid1 daemon is not running (systemctl communicates with and controls the pid1 daemon to load and kill services). I'm hoping this will make it in sooner or later, since it's basically the main remaining gap for a fully-functional userspace environment.

In the meantime, you can write a script to manually start and kill sshd by directly launching the binary.

[fpqc]

yeah.

Systemd is a big blocker for a lot of stuff, but the team has been reticent wrt promising support, although they seem to have dropped quite a few hints if you've been paying attention. Running sshd without systemctl/systemd is painful, for example.

[fpqc]

Arch uses more recent binaries that hit more unimplemented syscall surface.

[fpqc]

I just posted an example in fakeroot/makepkg that doesn't work without recompiling fakeroot to use tcp instead of semaphores. Also, the latest version of strace in the arch userspace fails on an unimplemented ptrace option. We're getting there though.

[kayakyakr]

I don't know if services are a huge blocker aside from a few cases here and there (sshd being probably the most useful example). Docker for Windows has supported each service that I was looking for and I think it's a much more natural "windows" environment than trying to provide those services through WSL.

This seems to be a pretty big thing and I'd much rather them figure out an access layer between VolFS and Windows than spend time supporting services.

[fpqc]

@kayakyakr Systemd support is a natural result of more syscall support and a relatively small amount of reworking of the init daemon (separating initialization and marshalling). Solving the VolFS share problem seems to be a real engineering problem in its own right, all solutions to which have pretty evident drawbacks or complications.

[kayakyakr]

I suppose I have been corrected.

The other side of it will be improving support for DrvFS which will improve speed and capability over time. I'mma get back on the fast ring to try out the speed since #966 is fixed now.