16.04: Graphical login/desktop vanished? (coming closer)

Tom H tomh0665 at gmail.com
Wed Jul 27 12:37:28 UTC 2016

On Wed, Jul 27, 2016 at 4:32 AM, Ralf Mardorf <silver.bullet at zoho.com> wrote:
> On Wed, 27 Jul 2016 03:13:55 -0400, Tom H wrote:
>> On Tue, Jul 26, 2016 at 5:06 PM, Ralf Mardorf <silver.bullet at zoho.com>
>> wrote:
>>> On Tue, 26 Jul 2016 19:21:29 +0200, Oliver Grawert wrote:

>>>> from https://www.debian.org/doc/debian-policy/ch-opersys.html
>>>> section 9.3.2
>>>> "The /etc/init.d scripts must be treated as configuration files,
>>>> either (if they are present in the package, that is, in the .deb
>>>> file) by marking them as conffiles, or,...."
>>>> "...Only when dpkg is executed with the --purge option will
>>>> configuration files be removed. In particular, as
>>>> the /etc/init.d/package script itself is usually a conffile, it will
>>>> remain on the system if the package is removed but not purged. "
>>>> so the behaviour is expected ... that the generator kicks in in this
>>>> case smells like a bug though, it might need to check if the related
>>>> package actually exists on the system...
>>> That's indeed rational, but tricky. What's inside of init.d is
>>> nebulous. One one side it quasi could be a "config" to manage a
>>> service, on the other side it quasi could be the "program" itself.
>> The main part of what the generator does is create a service unit in
>> "/run/" with
>> ExecStart=/etc/init.d/<daemon> start
>> ExecStop=/etc/init.d/<daemon> stop
>> so it's not that tricky.
> It isn't related to the generator, but to the package management.
> The wicked part is "apt-get remove", assumed the systemd unit and the
> program to run should be removed, but the init.d file should be
> considered as a config, that should not be removed. Again, the content
> of init.d is neither fish nor fowl, it's not really heisenbergish,
> since we can take a look and then we definitively know, if it's fish or
> fowl. However, regarding Oli's quote, it's per se a config for the
> package management.

You say: 'the init.d file should be considered as a config": no, a
"conffile", which is a special type of file not simply a "config file"
or "configuration file."'

$ dpkg -s lightdm | grep -A 12 Conffiles
/etc/apparmor.d/abstractions/lightdm 14606b0b6aeb01259d40ec740caad0be
/etc/apparmor.d/lightdm-guest-session 3c7812f49f27e733ad9b5d413c4d14cb
/etc/init.d/lightdm be2b1b20bec52a04c1a877477864e188
/etc/init/lightdm.conf 07304e5b3265b4fb82a2c94beb9b577e
/etc/lightdm/users.conf 1de1a7e321b98e5d472aa818893a2a3e
/etc/logrotate.d/lightdm b6068c54606c0499db9a39a05df76ce9
/etc/pam.d/lightdm 1abe2be7a999b42517c82511d9e9ba22
/etc/pam.d/lightdm-autologin 28dd060554d1103ff847866658431ecf
/etc/pam.d/lightdm-greeter 65ed119ce8f4079f6388b09ad9d8b2f9
Description: Display Manager

These are the files that

(1) if you upgrade a package after you've modified them, you get a
debconf dialog box whereby, if you answer Y or I, the new file's
installed and the current file's saved with a "dpkg-old" suffix and,
if you answer N or O, the current file's kept and the new file's
installed with a "dpkg-dist" suffix. There's a similar behavior if ucf
is used rather than debconf. You'd mentioned pacnew and pacold in an
earlier email; I'm pretty sure that dpkg/apt have behaved this way
long before pacman existed. The other PMs with which I'm familiar,
rpm/yum/dnf and emerge, have similar concepts and behaviors.

(2) if you remove a package rather than purge it, they're kept.

So there's no wickedness, except that, it seems to me, that when I
purge a package, its dependencies are removed rather than purged so I
have to run "apt-get purge $(aptitude search -F %p ~c)" to purge the
dependencies. There's probably a dpkg preference that I could set for
dependencies to be purged too but I've never looked. As someone who
started out with RHL and who's job mostly involves RHEL, I've always
found dpkg/apt's remove/purge and upgrade/dist-upgrade bizarre and a
PitA. But this is how Debian and Ubuntu are set up so I've adapted to
their choices.

> Anyway, it wasn't my point, but thank you for mentioning it, there's
> also something wicked related to the generator. ExecStart and ExecStop
> isn't a translation of the runlevels an init script could provide.
> Perhaps the genrator does a better translation, but the translation
> isn't that simple.

I don't follow. In systemd you can only start and stop, and reload, if
it's defined. So it makes sense that the generator only creates
ExecStart and ExecStop. I have no idea whether the generator'll create
an ExecReload if a "reload()" function or a "reload)" "case" statement
are defined in the rc script. The generator also uses the LSB headers
to set up the dependencies (unless, IIUC, they're in runlevels S and
1). Anyway, sooner rather than later the sysv generator'll be a no-op
because the distros that currently use it will ship systemd service
files for all daemons, if only because they'll be shipped by the
various upstreams.

If you were so inclined, you could grab systemd units from
Arch/Fedora/Gentoo (and adjust executable paths if need be) in order
to override an Ubuntu package only shipping "/etc/init.d/<daemon>".
I've done so for samba. IIRC, samba upstream now has its own units,
like nfs, so you could even get them from there.

More information about the ubuntu-users mailing list