Comment 7 for bug 260443

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Hi Martin-

I just uploaded update-motd_1.3, hopefully addressing all of your concerns, and preserving most of the functionality that I really wanted to keep.

You can see the changelog in the last 2 uploads for per-file change documentation, but I'll explain here for continuity...

The dpkg-reconfigure continues to prompt for:
 * RUN=true|false

If RUN=true, then it will also prompt for:
 * FREQ_IN_MIN, default to the current user-specified value as extracted from /etc/cron.d/update-motd, or "10" if unspecified.

If RUN!=true, the cronjob will be removed entirely, saving CPU-cycles.

The value of RUN is written to the /etc/default/update-motd configuration file, which is sourced by /etc/init.d/update-motd, and determines whether or not the update-motd init script will start the "daemon" (by touching /var/run/update-motd.enabled).

The value of FREQ_IN_MINUTES is written to /etc/cron.d/update-motd by injecting the value into a template stored at /usr/share/update-motd/update-motd.cron. On package configuration/reconfiguration/upgrade, this value is seeded and read from /etc/cron.d/update-motd. The note at the top of that file remains, warning users that it would be best to use dpkg-reconfigure update-motd to regenerate that file.

If the init script /etc/init.d/update-motd was able to start update-motd (ie, RUN=yes, and the cronjob exists), then a file is touched, /var/run/update-motd.enabled. This is basically the equivalent of a "pidfile", except that update-motd runs as a cronjob rather than a daemon, and as such, has no pidfile.

The executable /usr/sbin/update-motd now checks that /var/run/update-motd.enabled exists, although it does allow for a --force override. It's basically a no-op in the case where /var/run/update-motd.enabled does not exist, and prints an error message informing the user how they might go about re-enabling update-motd.

With these changes, I think we both get what we want...

From your perspective, /etc/init.d/update-motd no longer inserts FREQ_IN_MIN; that is *only* handled by the dpkg-reconfigure.

From my perspective, FREQ_IN_MIN is still "dpkg-reconfigure enabled", and the user can stop update-motd either permanently (across reboots) using dpkg-reconfigure, or temporarily (within the current boot) using "/etc/init.d/update-motd stop".

Regarding your comment about being "over engineered"... The update-motd process runs as a simple cronjob, as opposed to spawning a real daemon. The non-standard things I might have written into the init.d script are as a result of this. Perhaps in an update-motd_2.0 version, I can write a simple daemon, but that's for a future feature request...

:-Dustin