Sendmail uninstall leaves binary behind - bug?

I use Exim on all my installs, so the normal step for me is to uninstall Sendmail. A while ago I noticed that all my machines still had the Sendmail binary on them even after Sendmail was removed. Looking at the uninstall log, I think the following line is the culprit:

  --> /usr/sbin/sendmail.new no longer exists. Skipping.

Is there a bug in the Sendmail package? Everytime I uninstall Sendmail, I have to remove the binary manually.

I don't know why it's done this way, but the sendmail binary is added to the package as sendmail.new and then the doinst.sh will rm any existing /usr/bin/sendmail and move the .new file over. I suppose removepkg doesn't catch this and it isn't removed when the package is removed.

SlackBuild-sendmail

cd obj.$OSCPU/sendmail
cat sendmail > $PKG/usr/sbin/sendmail.new

doinst.sh

# Install new sendmail binary:
rm -f usr/sbin/sendmail
mv usr/sbin/sendmail.new usr/sbin/sendmail

Can this be reported somewhere/to somebody?

There's a "requests for -current" thread at the top or you can email Pat directly at volkerdi at slackware dot com.

Thank you for the tip! I didn't think of the requests thread.

Originally Posted by bassmadrigal I don't know why it's done this way, but the sendmail binary is added to the package as sendmail.new and then the doinst.sh will rm any existing /usr/bin/sendmail and move the .new file over. I suppose removepkg doesn't catch this and it isn't removed when the package is removed. SlackBuild-sendmail cd obj.$OSCPU/sendmail cat sendmail > $PKG/usr/sbin/sendmail.new doinst.sh # Install new sendmail binary: rm -f usr/sbin/sendmail mv usr/sbin/sendmail.new usr/sbin/sendmail

root:/usr/sbin# cp sendmail.orig sendmail 
/bin/cp: cannot create regular file 'sendmail': Text file busy
root:/usr/sbin# mv sendmail.orig sendmail

The same "name binary as .new and then move it over existing one" code exists for bash and other files that may be running at that time and cannot be copied.

Originally Posted by imitheos root:/usr/sbin# cp sendmail.orig sendmail /bin/cp: cannot create regular file 'sendmail': Text file busy root:/usr/sbin# mv sendmail.orig sendmail The same "name binary as .new and then move it over existing one" code exists for bash and other files that may be running at that time and cannot be copied.

While that can be a problem when you try and copy a file over a running executable with a command like cp, tar does an unlink() if the open() of the target file fails with EEXIST and then tries again: the new file gets a new inode and all should be dandy. Unless I'm missing something the mv something{.new,} dance shouldn't be necessary just because of the behaviour shown above.

Originally Posted by GazL While that can be a problem when you try and copy a file over a running executable with a command like cp, tar does an unlink() if the open() of the target file fails with EEXIST and then tries again: the new file gets a new inode and all should be dandy. Unless I'm missing something the mv something{.new,} dance shouldn't be necessary just because of the behaviour shown above.

What you are missing is the unfortunate consequence of a failure during the writing of the new file. If you've already unlinked the old one, you are left with nothing. The safe sequence is to write the new file under a temporary name and then, once the writing has completed successfully, relink it to the original name. The relinking is atomic -- it either succeeds or leaves things as they were.

Originally Posted by rknichols What you are missing is the unfortunate consequence of a failure during the writing of the new file. If you've already unlinked the old one, you are left with nothing. The safe sequence is to write the new file under a temporary name and then, once the writing has completed successfully, relink it to the original name. The relinking is atomic -- it either succeeds or leaves things as they were.

Yep, I'm well aware of rename() being atomic. It's a technique I use myself.

For something like /sbin/init I can understand a little extra precaution along those lines. But very few files get the '.new' treatment in slackware packages and I don't see how the sendmail binary is any more important than many others: many of which, unlike sendmail, would probably result in an unbootable system if the write during package installation was to fail for whatever reason.

Sorry, I don't buy protection against a partial/failed package extraction as the reason in this case.

I have come across this sort of thing before. It looks to be a generic problem with removepkg and .new files. If the package has any .new files then corresponding renamed files are never deleted.
A patch would need to expand what delete_files() does. If a file name ends .new, then:
- don't report an error if it doesn't exist
- remove the file without the .new suffix, report an error if it doesn't exist
- BUT don't remove the renamed file if removepkg was invoked by upgradepkg
- needs a new command-line argument to removepkg, to tell it whether to remove renamed .new files or not

Worth doing? I'm up for giving it a go if others think it is

I generally prefer the existing behaviour of leaving the renamed files in place: they're typically config files that I may have altered and most likely will want to manage manually.

There are a couple of oddities where files are given a ".new " extension but are unconditionally renamed during the doinst.sh e.g. bash and sendmail. In these cases -- and if this rename dance is really necessary -- I think I'd prefer to see something like ".incoming' used instead of ".new" to differentiate them from the ones intended to be handled manually by the sysadmin.

Originally Posted by imitheos The same "name binary as .new and then move it over existing one" code exists for bash and other files that may be running at that time and cannot be copied.

Imitheos, my apologies. You were right.


I just compared a strace of tar-1.13 to tar-1.29 and the tar-1.13 (used by pkgtools) doesn't open with O_EXCL and there is no unlinking during the extraction and it goes splat.

Which makes me wonder now how many other packages have failed to install because of this, bash and sendmail surely can't be the only executables that are likely to be running when you do updates. How does /sbin/udevd ever get updated?

I also remember glibc getting special treatment (using the "incoming" suffix as you suggested) which of course is logical but there are surely more packages.

/sbin/udevd gets updated fine if you do it in single-user as recommended - it doesn't run then.

I agree that, absent a new command-line option, removepkg should continue to behave as it does now. Except, perhaps, it could stop complaining about .new files that no longer exist.
I do think we need an extra argument (maybe --remove-renamed-new) e.g. when upgrading from one Slackware version to the next. As an example, Slackware 14.0 upgrade instructions specify to removepkg hal This leaves behind /etc/dbus-1/system.d/hal.conf, which was distributed as hal.conf.new. A new option to remove renamed .new files would have cleared that.
(removepkg hal also leaves behind 3 dangling symlinks in /usr/libexec/scripts/linux that were put there by doinst.sh but I'm not proposing to to anything about that).