Your old notes are incorrect. First, the proper command on modern Unix or Unix-ish systems such as Linux is simply:

sudo crontab -e -u mailman

Copy and paste the crontab provided with Mailman in the ~mailman/cron directory into the edit window opened by this command.

The crontab provided with Mailman in ~mailman/cron/crontab.in is not in the proper format for use in /etc/cron.d/ so a direct copy of the Mailman crontab to this directory can't be done without modifying the file. The directory /etc/cron.d/ is Debian-specific (which includes Debian derivatives such as Ubuntu and Mint) and a direct copy to cron's spool directory, /var/spool/cron/, is advised against in the cron man page. It's best to go through the UI provided by crontab and use your CLI editor (vim, pico, emacs or whatever) to manage the crontab.

See the man page for cron(8) and crontab(1)

On Tue, 2015-04-21 at 11:56 +0300, Danil Smirnov wrote:

Check if you already have /etc/cron.d/mailman, if not just

cp /opt/local/share/mailman/cron/crontab.in /etc/cron.d/mailman

with sufficient rights.

2015-04-21 8:21 GMT+03:00 Bill Christensen <billc_lists@greenbuilder.com>:

...

Hi all,

I recently updated and my digests stopped going out (I was able to push out the waiting digest manually by doing /opt/local/share/mailman/cron/senddigests so I know the function is working). My old notes tell me the command for cron is:

sudo /opt/local/share/mailman/cron/crontab -u mailman crontab.in

I also tried

sudo /opt/local/share/mailman/cron -u mailman crontab.in

since that appears to be the current location of crontab.in

but that's getting me 'command not found' and

  cron: illegal option -- u

 usage: cron [-s] [-o] [-x debugflag[,...]]

 debugflags: ext sch proc pars load misc test bit

Any ideas on this?

---

Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/fmouse%40fmp.com

-- Lindsay Haisley | "The only unchanging certainty FMP Computer Services | is the certainty of change" 512-259-1190 | http://www.fmp.com | - Ancient wisdom, all cultures

2015-04-21 17:43 GMT+03:00 Danil Smirnov <danil@smirnov.la>:

2015-04-21 17:24 GMT+03:00 Lindsay Haisley <fmouse@fmp.com>:

...

so a direct copy of the Mailman crontab to this directory can't be done without modifying the file.

You are right but not because of improper format of crontab.in file:

# This file is copied to /etc/cron.d/mailman from # /usr/lib/mailman/cron/crontab.in when the mailman service is started via its # init.d script and the file /etc/cron.d/mailman is removed when the # service is stopped. Therefore any edits made directly to # /etc/cron.d/mailman will be lost anytime the mailman service # restarts. # # To make changes edit the master copy /usr/lib/mailman/cron/crontab.in and then # restart the service to pick up the changes (/sbin/service mailman restart). # # The reason this is done this way is because the mailman cron jobs # should only be invoked if the mailman service is enabled and not # just as a consequence of installing the rpm as was the case # previously. The file /etc/cron.d/mailman cannot simply be linked to # the master copy in /usr/lib/mailman/cron because for security reasons cron # will not process crontab files that are links or writeable by # anybody else but root, thus the file must be copied into /etc/cron.d # with the right ownership and permissions.

Danil

This thread is getting too convoluted for me to parse, but here's the complete story:

There are two possible places where Mailman's crontab can be installed. For purposes of discussion, assume the Mailman user on your server is 'mailman'.

• The crontab can be a user crontab in /var/spool/cron/mailman or maybe /var/spool/cron/crontabs/mailman. This can be installed by

sudo cp /path/to/mailman/cron/crontab.in /var/spool/cron/mailman

(or to /var/spool/cron/crontabs/mailman after verifying the place) or better because you don't need to know the destination

sudo crontab -u mailman < /path/to/mailman/cron/crontab.in

• the crontab can be a system crontab in /etc/cron.d/. The file name is not important but is usually 'mailman' for documentation reasons. Because these crontabs do not have a user context, the format is different. There is an additional field between the days/times and the command which is the user under which to run the command. Mailman's cron/crontab.in (as distributed by the GNU Mailman project) does not have this field. Thus, if you were to install /path/to/mailman/cron/crontab.in directly in say /etc/cron.d/mailman you would need to edit it to change lines like

0 8 * * * /usr/bin/python -S /var/MM/21/cron/checkdbs

to

0 8 * * * mailman /usr/bin/python -S /var/MM/21/cron/checkdbs

The important thing is there should be only one of these two possible crontabs. It doesn't really matter which, but if you have both, you'll run all the crons twice which will result in duplicate emails being sent to users and list owners.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Tue, Apr 21, 2015 at 11:32:48AM -0500, Lindsay Haisley wrote:

The bottom line is that it's best, as always, to install a component such as a crontab using the supplied tools rather trying to second-guess the tool set and copying files directly.

This makes me wonder if it might be useful to have two files in the Mailman source:

mailman/cron/crontab.in-system
mailman/cron/crontab.in-user

with -system including the 'user' column?

Were the 'offical' source for Mailman be GitHub, there'd be a PR already, handling that.

-- "Youth cannot know how age thinks and feels. But old men are guilty if they forget what it was to be young" -- JK Rowling ('Harry Potter and the Order of the Phoenix')

On Tue, Apr 21, 2015 at 10:16:48AM -0700, Mark Sapiro wrote:

On 04/21/2015 09:42 AM, Adam McGreggor wrote:

...

This makes me wonder if it might be useful to have two files in the Mailman source:

mailman/cron/crontab.in-system
mailman/cron/crontab.in-user

with -system including the 'user' column?

Why? Our distribution works when installed per our docs. Downstream packages also tend to do the right thing. Problems tend to occur only when users of packages try to follow our documentation rather that the packager's.

Reading more of the thread, I think that's something that wasn't clear to me; the mixed approach of remnants of a package install, then a source install.

...

Were the 'offical' source for Mailman be GitHub, there'd be a PR already, handling that.

Just FYI and not addressing the issue of, PRs vs. branches vs. bzr merge proposals, Mailman 3 will probably use GitLabs as it's official repository. We're not there yet, but we recognize that Bazaar lost the war.

I think that will help drive community contributions, immensely. It's one barrier removed.

We can't use GitHub because GitHub uses proprietary software and as a GNU project, we get into issues with FSF if our complete stack is not open source.

*sigh* (and probably better not mentioning further; at least in this (sub-)thread).

-- "Get me a beer. I don't care what kind it is, just get me a beer!" -- Duke of Edinburgh, on being offered the finest Italian wines by PM Giuliano Amato at a dinner in Rome in 2000.

On 04/21/2015 09:32 AM, Lindsay Haisley wrote:

On Tue, 2015-04-21 at 18:46 +0300, Danil Smirnov wrote:

...

# This file is copied to /etc/cron.d/mailman from # /usr/lib/mailman/cron/crontab.in when the mailman service is started via its # init.d script and the file /etc/cron.d/mailman is removed when the # service is stopped. Therefore any edits made directly to # /etc/cron.d/mailman will be lost anytime the mailman service # restarts.

I think this needs to be revisited. I don't believe Mailman does this anymore. Mark, does a bug need to be filed on this?

This is a packager thing (RHEL/CentOS ?). Mailman as distributed by the GNU Mailman project does not do this (never did). Our docs are <http://www.list.org/mailman-install/node41.html> and recommend installing our crontab as a user crontab with the crontab command.

...

The bottom line is that it's best, as always, to install a component such as a crontab using the supplied tools rather trying to second-guess the tool set and copying files directly.

+1

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan