during winbind upgrade running desktop is harmed

Binary package hint: samba

When using Winbind to provide user NSS information, restarting Winbind for any long period can cause Very Bad Things. The current desktop session will for instance not be able to find $HOME, nor even it's own user name. Applications break. Browsers won't open. Various things crash. This is pretty expected. NSS information is important.

During a distro upgrade that involves Winbind, Winbind is usually stopped fairly early in the process, only to be started again near the end. This is not unlike most daemons. Except, in Winbinds case, it is fairly disasterous. Programs the user has open during the upgrade can crash unexpectadly. New programs won't open. This usually solves itself when Winbind comes back up, but the time period that it is down varies greatly depending on the size of the upgrade the user is running. It is very non-professional to have the desktop start randomlly failing during an upgrade. Also it's annoying.

In addition to this, there is the chance that some package in the upgrade will fail. Maybe a package which is completely unrelated to Winbind. This might cause dpkg to stop processing packages and go into a failed state. Not a big deal usually except in this case the user's desktop is broken! This should be prevented against as much as possible.

I propose that Winbind be handled a bit more gingerly. Perhaps it not be stopped during the upgrade process, and only quickly restarted in the postinst or even as a trigger, after all processing has completed. A check that the syntax of smb.conf is correct before doing the restart would be nice as well. The replacement of files during the upgrade itself should not harm the running Winbind. If it does, that should be addressable pretty easily.