smbd/nmbd don't restart after upgrade if started but disabled

[Alan Franzoni]

If smbd and nmbd are started and running but their service is disabled, and an apt-get upgrade is performed which updates samba/samba-common, at the end of the upgrade the smbd and nmbd daemons will not be running anymore.

Distribution: Ubuntu 16.04

Pre-upgrade version: 4.3.8+dfsg-0ubuntu1
Post-upgrade version: 4.3.11+dfsg-0ubuntu0.16.04.12

What I expected to happen:
After the dist-upgrade, since smbd and nmbd services were running, they should have been started again

What happened instead:
smbd and nmbd services are inactive.

The problem doesn't arise if the service is enabled; I suppose that somewhere after the upgrade, the samba package queries for the global unit enablement status rather than the unit status before the upgrade; this is especially problematic with unattended-upgrades, there're reasons for which I don't start samba at boot (it gets started by an ansible task after a disk is checked, decrypted and mounted), and it has happened to me to have a machine with samba properly running and then dead after an automated upgrade.

[Andreas Hasenack (ahasenack)]

I can confirm this behavior in xenial, but to be honest I'm not sure what's the correct expected outcome.

Can you perhaps accomplish something similar using /usr/sbin/policy-rc.d? You can create that script and it would check if samba is the service being started, and then check if the disk you need is verified and decrypted, and do nothing otherwise.

See this bug and its comments 7 and 8 for an example: https://bugs.launchpad.net/ubuntu/+source/freeradius/+bug/1712817

Would that work for you?

[Alan Franzoni (alanfranz)]

Uhm, so I should ENABLE the service, and then prevent it from starting? Isn't that a bit convolute? Also, in the other ticket you say that "The debian and ubuntu way is that if you don't want it running, you shouldn't install it." -> may I ask where this fact is stated? My understanding was that an upgrade should not alter the state of the system - if a service is running and must be restarted after an upgrade, it is restarted, otherwise it's left alone (the try-restart use-case). I've never seen stated that after an upgrade a service should pick the state which is currently mandated by the runlevel/init system, and it's the first time it happens to me (in other contexts, I would start services via ansible/puppet).

Sure, your workaround might work. But the "the correct expected outcome", IMHO, is that the status of a service (started/stopped) should be the same before and after an upgrade, regardless of whether the unit is active or inactive.

To me, this seems to be the behaviour of whatever I've encountered on Debian/Ubuntu/Centos in the last 10 years (barring bugs).

I did a couple of cross checks for some system packages, and everything I tested (nginx, apache) seems to work this way; I even just checked nginx on Ubuntu 14.04 and works as stated above (i.e. service is disabled but started, after upgrade it's restarted properly).

If you need more specific data I'll provide you with that... maybe it's a matter that there's no consensus on Debian/Ubuntu about the topic, but I'd say it's high time that such consensus is created.

[Andreas Hasenack (ahasenack)]

> Uhm, so I should ENABLE the service, and then prevent it from starting?

You would be adding a condition for it to start. Native systemd services can have such conditions in the service definition file, but in xenial samba is not one of those I'm afraid. In fact, the samba package has a mess of 3 init systems config files in it in xenial: sysv, upstart and systemd.

> Isn't that a bit convolute?

It's not the most common scenario: only start the service if a certain mount point is in use?

All that being said, it was my personal honest statement when I said i wasn't sure what the right outcome would be in such a case: service disabled, but running (started manually), and an upgrade comes along. It's excellent that you found these other packages which behave differently. Do they have native systemd service files, or are they using the sysv compatibility feature like samba is?

[Launchpad Janitor (janitor)]

[Expired for samba (Ubuntu) because there has been no activity for 60 days.]