1

I am handling nearly 30 packages and have all sorts of files and scripts that get installed.

Some of those scripts can run while the package is installed, but once removed (opposed to purged), they should not be executed anymore.

How is that being managed in standard Ubuntu/Debian packages?

For example, I have a logrotate file that gets installed with:

/var/log/snapwebsites/snapmanagerdaemon.log {
    weekly
    maxsize 10M
    su snapwebsites snapwebsites
    missingok
    rotate 10
    postrotate
        /usr/bin/snapsignal snapmanagerdaemon/LOG
    endscript
    compress
    delaycompress
    notifempty
    create 640 snapwebsites snapwebsites
}

The /usr/bin/snapsignal binary will disappear if all the packages get removed, but this logrotate script stays in place... so when it gets run, it fails on that one call.

I thought I could do a remove in the postrm script as in:

if [ "$1" = "remove" ]
then
    rm -f /etc/logrotate.d/snapmanagerdaemon
fi

That works for the remove step, but if the user re-installs the package, it does not come back (it does not get unpacked.) So as a result, I would not got the expected log rotation. At least no until I forcibly extract that file and re-install it by hand.

I can see several solutions, but I'd like to know how it is done in a proper Debian package.

One solution that would work, is for me to add a test to know whether snapsignal is still installed.

    postrotate
        if test -x /usr/bin/snapsignal
        then
            /usr/bin/snapsignal snapmanagerdaemon/LOG
        fi
    endscript

Only that means logrotate continues to run this entry forever even though that package is gone. I have a similar feeling about the other scripts I manage. Once the package is removed, there should be no need to have such a script still running.

Note that the logrotate is one example exhibiting the problem. We actually noticed it with the dpkg configuration file, a script we place under:

/etc/dpkg/dpkg.conf.d/...

which remains in place after a remove.

Another type of script that stays behind and will also cause problems: CRON files. Those that you install under /etc/cron.daily, /etc/cron.monthly, etc. If any one of those scripts try to access one of your binary files after a remove, it will fail.

| improve this question | | | | |
  • Of interest: debian.org/doc/debian-policy/ch-files.html#s10.8 – muru Nov 11 '16 at 0:51
  • @muru, and my point is that the command start-stop-daemon -K -p /var/run/foo.pid -s HUP -x /usr/sbin/foo -q fails if foo gets removed (not purged). And it looks like they do not speak of that situation... – Alexis Wilke Nov 11 '16 at 4:27
0

With the help of some other people, I found an answer in the Debian policy document, but this is only spelled out in the CRON Jobs section (opposed to a more generic section about such scripts.)

The concerned paragraph:

The scripts or crontab entries in these directories should check if all necessary programs are installed before they try to execute them. Otherwise, problems will arise when a package was removed but not purged since configuration files are kept on the system in this situation.

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.