pure systemd systems

[heartsucker]

pure systemd systems

[heartsucker]

From the systemctl manpages:

preset NAME...

    Reset one or more unit files, as specified on the command line, to the defaults configured in the preset policy files. This has the same effect as disable or enable, depending how the unit is listed in the preset files.

    Use --preset-mode= to control whether units shall be enabled and disabled, or only enabled, or only disabled.

    For more information on the preset policy format, see systemd.preset(5). For more information on the concept of presets, please consult the Preset document.

So to me this looks like systemctl enable $service should cover it. We don't use any systemd based OS's at work, and I built support for this as a convenience for everyone else, so I don't have complete knowledge of how it works.

If you can find a link explaining why the preset command should be added, I'll look into it further.

[empierre]

Hello,

I understand and appreciate your work here.

I've bumped in that issue on installing on a ubuntu 15.10(which are the latest), all was fine except it wasn't activated... so service was not started on reboot.

[heartsucker]

Word. I'll see if I can reproduce it on a VM and see if that change fixes it.

[empierre]

also had issues of npm unpak issues, had to add this to correct the issue (clean cache and install as an unprivillegied user:

preinst:
npm cache clean

postint:
chown 'www-data:www-data' '/var/www/'
chown -R 'www-data:www-data' '/usr/share/mydomoathome'

npm_install() {
cd "/usr/share/$1/app"
if [ -e 'node_modules' ]; then
rm -rf 'node_modules'
fi
sudo -u www-data npm install --production
}

[heartsucker]

@empierre I tested this on an Ubuntu 15.x VM and a Debian 8 VM, and the services appears to survive the restart with just systemctl enable and systemctl start in the postinst script. I'm marking this as "won't fix." I'm opening a second ticket about the ownership problems on the files.

[empierre]

Looking to literature as other user reports issue on others init system I found this:

if hash service 2> /dev/null; then
if [[ "$init_type" == 'auto' || "$init_type" == 'upstart' ]]; then
service "$service_name" start || echo "${service_name} could not be registered or started"
service enable "$service_name"
fi

enable is required to start automatically on next reboot, equivalent here for upstart:

elif hash start 2> /dev/null; then
if [[ "$init_type" == 'auto' || "$init_type" == 'upstart' ]]; then
start "$service_name" || echo "${service_name} could not be registered or started"
echo ENABLED=1 > "/etc/default/$service_name"
echo start > "/etc/init/$service_name.override"
fi

[empierre]

some user reported this too on PI (don't know if this is PI 1 or 2

pi@domoticzpi ~ $ sudo service mydomoathome status
● mydomoathome.service - MDAH ISS Rest interface for Domoticz to Imperihome
Loaded: loaded (/etc/systemd/system/mydomoathome.service; disabled)
Active: inactive (dead)
pi@domoticzpi ~ $ sudo service mydomoathome start