Question on cron.in and the init.d scripts in rpm file
Hello all, setting up mailman on linux 2.6.9 where mailman was installed I believe by a rpm file.
The question is about the cron job. The documentation says to install the contents of the supplied file into the cron job of the user mailman
% cd $prefix/cron
% crontab -u mailman crontab.in
Upon doing so, I got error messages from the cron job when it ran
/bin/sh: mailman: command not found
The cron entry failing looks like this 0,5,10,15,20,25,30,35,40,45,50,55 * * * * mailman /usr/lib/mailman/cron/gate_news
The syntax didn't look right to me because, what was 'mailman' doing there at the start of the command? the shell setup by cron can not find the mailman executable because its not installed in /usr/bin or /usr/sbin . My install is into /usr/lib/mailman and /var/lib/mailman
Mark Sapiro offers an explanation in this archived message from the list http://www.mail-archive.com/mailman-users@python.org/msg43115.html
Saying its due to a package setup and just remove 'mailman'. I can do that, but reading the actual crontab.in file supplied suggests that the cronjob is automatically setup and torn down by the init.d script
# 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).
Ok - makes sense.. so I should edit the file in /usr/lib/mailman/cron/crontab.in and the script will update the actual cron job when the service is started..
So, I'll edit out mailman in /usr/lib/mailman/cron/crontab.in - but is this something lacking in the documentation? I don't understand why the crontab.in file has that extra mailman in each of the lines of the crontab. Does it serve a purpose for other installation types?
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Ok, I found that if placed in /etc/cron.d the file is intended as a crontab which has the userfield as part of the command.. so the default crontab.in file is correct for that usage - but doesn't this mean the documentation is INCORRECT to tell you to directly install that file into the mailman's crontab using crontab -u mailman filename ?
steve <flynnibus@yahoo.com> wrote: Hello all, setting up mailman on linux 2.6.9 where mailman was installed I believe by a rpm file.
The question is about the cron job. The documentation says to install the contents of the supplied file into the cron job of the user mailman
% cd $prefix/cron
% crontab -u mailman crontab.in
Upon doing so, I got error messages from the cron job when it ran
/bin/sh: mailman: command not found
The cron entry failing looks like this 0,5,10,15,20,25,30,35,40,45,50,55 * * * * mailman /usr/lib/mailman/cron/gate_news
The syntax didn't look right to me because, what was 'mailman' doing there at the start of the command? the shell setup by cron can not find the mailman executable because its not installed in /usr/bin or /usr/sbin . My install is into /usr/lib/mailman and /var/lib/mailman
Mark Sapiro offers an explanation in this archived message from the list http://www.mail-archive.com/mailman-users@python.org/msg43115.html
Saying its due to a package setup and just remove 'mailman'. I can do that, but reading the actual crontab.in file supplied suggests that the cronjob is automatically setup and torn down by the init.d script
# 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).
Ok - makes sense.. so I should edit the file in /usr/lib/mailman/cron/crontab.in and the script will update the actual cron job when the service is started..
So, I'll edit out mailman in /usr/lib/mailman/cron/crontab.in - but is this something lacking in the documentation? I don't understand why the crontab.in file has that extra mailman in each of the lines of the crontab. Does it serve a purpose for other installation types?
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/flynnibus%40yahoo.com
Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
steve wrote:
Ok, I found that if placed in /etc/cron.d the file is intended as a crontab which has the userfield as part of the command.. so the default crontab.in file is correct for that usage - but doesn't this mean the documentation is INCORRECT to tell you to directly install that file into the mailman's crontab using crontab -u mailman filename ?
The problem is you are following our "install Mailman from source" documentation, but you are installing a "packaged" Mailman which does things differently. You should be either installing from source and following our documentation or following the packager's documentation for installing the package. If the packager's documentation is missing or inadequate, that's not something we have any control over.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
steve writes:
Ok, I found that if placed in /etc/cron.d the file is intended as a crontab which has the userfield as part of the command.. so the default crontab.in file is correct for that usage - but doesn't this mean the documentation is INCORRECT to tell you to directly install that file into the mailman's crontab using crontab -u mailman filename ?
No. Mailman documentation refers to the distributed crontab which is in the usual user crontab format (no set-user field). It would work correctly as the mailman user's crontab.
steve <flynnibus@yahoo.com> wrote: Hello all, setting up mailman on linux 2.6.9 where mailman was installed I believe by a rpm file.
Almost certainly (based on past reports of this kind), something is messed up in your Linux installation. You could try to track it down yourself -- a common cause is installing an RPM intended for a different distribution, which isn't the distro's fault. It could be that the distro is broken, and may have even issued a bugfix upgrade.
Very likely this difference from the Mailman distribution is documented somewhere in the distro's docs. On Debian, try /usr/share/doc/mailman-$FULL_DEBIAN_VERSION.
On 1/4/08, steve wrote:
The question is about the cron job. The documentation says to install the contents of the supplied file into the cron job of the user mailman
% cd $prefix/cron % crontab -u mailman crontab.in
Upon doing so, I got error messages from the cron job when it ran
The installation instructions at <http://www.list.org/mailman-install/node41.html> are suitable for use with the source version of Mailman that you can download directly through our site. If you want to install a binary package version from some other provider, you should follow their installation instructions, because they may have made changes to where things are put, how things are put into place, etc....
-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>
participants (4)
-
Brad Knowles
-
Mark Sapiro
-
Stephen J. Turnbull
-
steve