postinst fails if the service is disabled via systemd

Do you still have your terminal log from before the bits you showed in the bug report?

Even if you have the service stopped, upgrading the packages would have restarted it, and the freeradius-ldap postinst would encounter the service running. Unless that earlier restart failed.

In freeradius.postinst, notice the "|| true" suffix ($action is either start or restart):
          invoke-rc.d freeradius $action || true

Then comes freeradius-ldap:
          invoke-rc.d freeradius force-reload

There the action will indeed fail if freeradius isn't runing.

Here are both scenarios. First, the failure:
oot@xenial-freeradius-1712817:~# systemctl stop freeradius.service
root@xenial-freeradius-1712817:~# apt install --reinstall freeradius-ldap
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/24.2 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 28097 files and directories currently installed.)
Preparing to unpack .../freeradius-ldap_2.2.8+dfsg-0.1ubuntu0.1_amd64.deb ...
Unpacking freeradius-ldap (2.2.8+dfsg-0.1ubuntu0.1) over (2.2.8+dfsg-0.1ubuntu0.1) ...
Setting up freeradius-ldap (2.2.8+dfsg-0.1ubuntu0.1) ...
freeradius.service is not active, cannot reload.
invoke-rc.d: initscript freeradius, action "force-reload" failed.
dpkg: error processing package freeradius-ldap (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 freeradius-ldap
E: Sub-process /usr/bin/dpkg returned an error code (1)

Now a proper upgrade, which includes freeradius itself:
root@xenial-freeradius-1712817:~# systemctl stop freeradius.service
root@xenial-freeradius-1712817:~# apt install --reinstall freeradius freeradius-ldap
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 2 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/550 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 28097 files and directories currently installed.)
Preparing to unpack .../freeradius_2.2.8+dfsg-0.1ubuntu0.1_amd64.deb ...
Unpacking freeradius (2.2.8+dfsg-0.1ubuntu0.1) over (2.2.8+dfsg-0.1ubuntu0.1) ...
Preparing to unpack .../freeradius-ldap_2.2.8+dfsg-0.1ubuntu0.1_amd64.deb ...
Unpacking freeradius-ldap (2.2.8+dfsg-0.1ubuntu0.1) over (2.2.8+dfsg-0.1ubuntu0.1) ...
Processing triggers for ureadahead (0.100.0-19) ...
Processing triggers for systemd (229-4ubuntu19) ...
Setting up freeradius (2.2.8+dfsg-0.1ubuntu0.1) ...
Setting up freeradius-ldap (2.2.8+dfsg-0.1ubuntu0.1) ...
root@xenial-freeradius-1712817:~#

I suspect the restart done by the freeradius postinst in your case failed and was masked by the "|| true" bit, or that the service started but died right afterwards.

Could you please check that your terminal had nothing else related to a freeradius restart before what you pasted in your bug report?

And also please attach a copy of /var/log/freeradius/radius.log as it may have inform...

In fact the problem is that freeradius is stoped and disabled:

  systemctl stop freeradius.service
  systemctl disable freeradius.service

So, the freeradius.postinst can not start it, then the freeradius-ldap.postinst fail.

Regards.

Ah, it's really disabled via systemd. Do you have any particular reason to have it installed but not running? The debian and ubuntu way is that if you don't want it running, you shouldn't install it.

I'll ask around here regarding the policy. Maybe we could add a "|| true" to the force-reload line, just like the "start/restart" one already has.

Yes, we provide an Ubuntu GNU/Linux derivatives for french national education, the software is installed and the admin can activate/desactivate it as wanted.

So the software is installed but can be disabled if the admin does not want it.

Regards.

Instead of adding “|| true”, it may have the possibility to check if the service is active and running?

systemctl:

       try-reload-or-restart PATTERN...
           Reload one or more units if they support it. If not, restart them instead. This does nothing if the units are not running.

As a workaround, you can create a /usr/sbin/policy-rc.d file with these contents:

#!/bin/sh
exit 101

# apt install --reinstall freeradius-ldap
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/24.2 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 28097 files and directories currently installed.)
Preparing to unpack .../freeradius-ldap_2.2.8+dfsg-0.1ubuntu0.1_amd64.deb ...
Unpacking freeradius-ldap (2.2.8+dfsg-0.1ubuntu0.1) over (2.2.8+dfsg-0.1ubuntu0.1) ...
Setting up freeradius-ldap (2.2.8+dfsg-0.1ubuntu0.1) ...
invoke-rc.d: policy-rc.d denied execution of force-reload.

You can also check the package name in that script, and return 101 only for the services you want to prevent from starting, and return 0 for the rest. "$1" is the service name.

Ok, so it looks like the following policy-rc.d will do the job for that particular case:

    #!/bin/sh

    skip_disabled() {
        local service="${1}"

        if [ -d /run/systemd ] && ! systemctl is-enabled "${service}" 2>&1 /dev/null
        then
            exit 101
        fi
    }

    case "${1}-${2}" in
        freeradius-reload)
            skip_disabled "${1}"
            ;;
    esac

Regards.

Thank you for reporting back.

I believe that in Debian and Ubuntu, policy-rc.d is the right way to adjust the system to get the behaviour you want, so I'm not sure there is any further action needed here from Ubuntu developers.

If you believe this is wrong, please do explain and reopen.

On second thought, perhaps invoke-rc.d should treat a systemd disabled service the same way as one done through the policy-rc.d mechanism. Whichever way, the correct behaviour should be decided package-wide by the invoke-rc.d wrapper, so I'm reassigning to init-system-helpers.

Based on https://irclogs.ubuntu.com/2018/04/13/%23ubuntu-devel.html#t11:56, this sounds valid for either init-system-helpers or debhelper.

13:47 <xnox> rbasak, the description sounds valid. i believe i have hit something similar before, thus yeah a fix to debhelper for this class of issues would be most welcomed.

13:47 <rbasak> xnox: thanks. debhelper, or invoke-rc.d?

13:48 <xnox> rbasak, my understanding was that maintainer scripts that are generated, do attempt to check if a thing was "enabled and active" before the upgrade; and post upgrade. But maybe they only do so for systemd native units, and not for init.d->systemd units.

Robie Basak:
> Based on https://irclogs.ubuntu.com/2018/04/13/%23ubuntu-
> devel.html#t11:56, this sounds valid for either init-system-helpers or
> debhelper.
>
> 13:47 <xnox> rbasak, the description sounds valid. i believe i have hit
> something similar before, thus yeah a fix to debhelper for this class of
> issues would be most welcomed.
>
> 13:47 <rbasak> xnox: thanks. debhelper, or invoke-rc.d?
>
> 13:48 <xnox> rbasak, my understanding was that maintainer scripts that
> are generated, do attempt to check if a thing was "enabled and active"
> before the upgrade; and post upgrade. But maybe they only do so for
> systemd native units, and not for init.d->systemd units.
>
>
> ** Also affects: debhelper (Ubuntu)
> Importance: Undecided
> Status: New
>

Hi,

Possibly related to this issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887904#10

Thanks,
~Niels