include systemd init setup files in hhvm proper?

[ghost]

Until recently it wasn't feasible to include distribution init scripts for distributions without some distribution users being left out in the cold. Now , though.. many distributions use (or will use) systemd in their default installations.

Here is a list of the distributions that offer systemd i know of:

• Fedora >= 15
• RHEL/CentOS >= 7.0
• Debian >= 8 (optionally in 7)
• Ubuntu >= 15.04 (optionally in previous/current versions)
• OpenSUSE >= 12.3
• ArchLinux (not sure when, but it's been awhile)
• Gentoo (optionally)
• most derivatives of the previously mentioned ones

That's pretty good coverage for one init system, so it'd be cool if HHVM could offer a basic one that users can use directly after installing from source.

[paulbiss]

Please open an issue at https://github.com/hhvm/packaging

[glensc]

PLD Linux (Th) does too, optionally, since 2012 @jrobeson

[glensc]

However, the unit files themselves should exist in main hhvm repo, including cmake integration, hhvm/packaging would just run build and install with proper -D options

[devurandom]

Draft:

[Unit]
Description=HHVM FastCGI daemon
After=network.target

[Service]
User=www-data
Environment=CONFIG_FILE=/etc/hhvm/server.ini
Environment=SYSTEM_CONFIG_FILE=/etc/hhvm/php.ini
EnvironmentFile=-/etc/default/hhvm
ExecStart=/usr/bin/hhvm --config ${SYSTEM_CONFIG_FILE} --config ${CONFIG_FILE} --mode server
ExecStartPre=/bin/rm -f /var/run/hhvm/hhvm.sock
Restart=on-failure

[Install]
WantedBy=multi-user.target

The ExecStartPre is necessary, because HHVM has severe problems, if the socket file already exists. (And it will exist, because it does not properly cleanup after itself.)

I use --mode server instead of --mode daemon, because that keeps HHVM in the foreground, whereas the latter would fork it into the background, which makes things like Restart=on-failure more difficult.

If you do not want to support a /etc/default/hhvm unit configuration file, the whole unit becomes a lot simpler, of course.

I also tried to implement automatic socket activation, but it appears there is more work necessary within HHVM itself to implement it. E.g. listen on a given FD instead of creating an own socket – it might be a good idea to implement this while cleaning up the socket-file-already-exists issue.

As I have hhvm.repo.authoritative = true set in server.ini, I also wrote this unit to populate the cache:

[Unit]
Description=HHVM FastCGI cache creation
Before=hhvm.service

[Service]
User=www-data
Type=oneshot
ExecStart=/usr/local/bin/hvvm-build-cache.sh /path/to/my/webapp
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

You need to enable it explicitly, and then Before=hhvm.service takes care of making the main HHVM unit wait until the cache is populated.

hhvm-build-cache.sh is:

#!/bin/bash

set -e

tmpdir=`mktemp -d`
output="${tmpdir}"/output
input="${tmpdir}"/input

onexit() {
        rm -fr "${tmpdir}"
}
trap onexit EXIT

for app in "$@" ; do
        find "${app}" -name '*.php' -fprint "${input}"
done

/usr/bin/hhvm --hphp --target hhbc --input-list "${input}" --output-dir "${output}"

chmod 0644 "${output}"/hhvm.hhbc
chown www-data "${output}"/hhvm.hhbc
chgrp www-data "${output}"/hhvm.hhbc
mv "${output}"/hhvm.hhbc /var/run/hhvm/hhvm.hhbc

[ghost]

I'm wondering why follks don't use a separate hhvm user for privilege separation. Is there any reason hhvm should run as www-data ?

[fredemmott]

Closing: this has more detail, but hhvm/packaging#102 is the right place for this.