gregor herrmann: > On Sat, 30 Jul 2016 18:40:21 +0000, Chris Knadle wrote: > > Hi Chris!
:)
>>>>> After the upgrade, chosing not to auto-start the daemon, I get this:
>
> So madduck has set START_IODINED to false in /etc/default/iodine
>
>>>>> ● iodined.service - A daemon for tunneling traffic over DNS queries
>>>>> Loaded: loaded (/lib/systemd/system/iodined.service; disabled; vendor
>>>>> preset: enabled)
>>>>> Active: activating (auto-restart) (Result: exit-code) since Wed
>>>>> 2016-07-27 13:17:34 CEST; 4ms ago
>>>>> Docs: man:iodined(8)
>>>>> Process: 2277 ExecStartPre=/bin/sh -xc test ${START_IODINED} = true
>>>>> (code=exited, status=1/FAILURE)
>
> and the new /lib/systemd/system/iodined.service exists with 1 because
> START_IODINED != true
>
>> Unfortunately I don't see what the failure is about.
>
> See above :)
Yep, got it. i.e. ... this behavior is unfortunately expected.
>> Something to note about this: systemd spitting out such a failure *does
>> not* mean that the service didn't start. One still needs to do a 'ps
>> -ef' and look for the service to make sure it's not running.
>
> Interesting ... but still, this failure means that dpkg aborts the
> upgrade, so we have a problem here.
Ohhhh. :-( Yeah that's obviously an issue that needs a solution.
> (And if the service runs its unwanted.)
>>>>> Please use systemd masking instead of the silly shell test and
>>>>> /etc/default/* file variable to control whether the daemon should be
>>>>> started.
>>> Sounds good, I just haven't found yet how to do this from the
>>> packaging side.
>> Enabling/disabling a service via an /etc/default file is not meant to be
>> done with systemd:
>> https://wiki.ubuntu.com/SystemdForUpstartUsers#A.2Fetc.2Fdefault_files_which_enable.2Fdisable_jobs
>
> Right. And
>
> "There is no clean way to evaluate these in a systemd unit. You can
> check them in ExecStartPre=, but that would mean that the unit will
> be in "failed" state if the service gets disabled that way, and so,
> is not desirable."
>
> matches what we see here.
I see that now.
What I think might be helpful here is the dh-systemd package,
specifically the dh_systemd_enable command:
Package: dh-systemd
[...]
Description-en: debhelper add-on to handle systemd unit files
dh-systemd provides a debhelper sequence addon named 'systemd' and the
dh_systemd_enable/dh_systemd_start commands.
.
The dh_systemd_enable command adds the appropriate code to the
postinst, prerm and postrm maint scripts to properly enable/disable
systemd service files.
The dh_systemd_start command deals with start/stop/restart on upgrades
for systemd-only service files.
Because basically what I think you want to happen is:
- systemd (in general) ignores the enable/disable environment
variable in the /etc/default file (because 'disabled' causes
problems), but will use any other environment variables
(This is what I see being done in Debian packages that
support systemd.)
- The postinst script runs 'systemctl enable iodined.service'
upon installation, and I think this could be done conditionally
based on the contents of the enable/disable env variable in
the /etc/default file.
I've had a quick look at the Debian Policy Manual, and /etc/default
files are discussed near the end of section 9.3.2, but it doesn't
discuss this in relation to systemd.
I've been considering this same issue ever since bug #780300.
>> I'm running systemd (and have for several years) and am happy to help
>> with this if I can.
>
> Thanks!
Glad to help where I can.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
signature.asc
Description: OpenPGP digital signature
