I have a list that often will go a day or so without any posts, which unhinges the next 2pm digest delivery. I have cronlist running daily, but have not figured out how to work .digest.force into the daily schedule. I've created it manually a few times and found that this helps the digest delivery. But how do I automatically create this file on a daily basis? Is it something that can be added to the cronlist or flush_digest scripts? Or should it be a separate cron job? How do I do this? TIA linda
At 11:09 PM -0400 10/5/00, Linda Wack is rumored to have typed:
I have a list that often will go a day or so without any posts, which unhinges the next 2pm digest delivery.
Er...if you have nothing to send, why would you want to send it in the first place?
I've created it manually a few times and found that this helps the digest delivery.
Yeah, I imagine it does; as the Manual clearly notes, .digest.force will force a digest release at the next invocation of flush_digests.
But how do I automatically create this file on a daily basis?
man touch
How do I do this?
In your shell script, called by cron: 1) chdir to your list directory 2) Check to see if you have anything in there to send by checking for the existance of archive/digest.body (man test will help here) 3) touch .digest.force 4) ../.bin/cronlist Although, personally, I think that's a complete waste of time and energy. Doesn't it make more sense to set the cronjob that calls .bin/cronlist to run four times a day, and set the timeout of the digest release around 20-to-22-hours? That way, you'll never run more than a day past when the first message hits the list, and won't be sending out tiny digests just because you want them released at one specific time per day. Unless you have an overriding reason for the digests to be released at a specific time (for example, offloading bandwidth usage to 2:00am or something), in which case you'd want to set your digest age and size variables in rc.custom to some whacked-out high number so it would _never_ be released automatically, and then control the entire process through the cron job. But that just seems unnecessary and wasteful to me under normal conditions. Charlie
At 11:02 AM 10/6/00 -0400, Charlie Summers wrote:
I have a list that often will go a day or so without any posts, which unhinges the next 2pm digest delivery.
Er...if you have nothing to send, why would you want to send it in the first place?
Because what happens is that after a day or two has passed without any list activity, one or more people will post in the morning, but the digest is not delivered on schedule in the afternoon. I have the digest age set to 24 hours, so the digest is initiated with a post, but not liberated until the following day. Yes, of course we do not require a digest when there has been no activity ;-) Sometimes this list is quite active, but will also go dormant for a day or so at a time. The digest subscribers want a daily digest in the afternoon, so they don't miss out on anything from earlier in the day. I've experimented with a variety of settings trying to find the right combination to generate at least one digest a day when there is activity. Your suggestions are welcome and appreciated!
2) Check to see if you have anything in there to send by checking for the existance of archive/digest.body (man test will help here)
I'm not sure that this one is necessary because I believe that flush_digests does this test and exits early if there is no digest.body (I don't have access to the flush_digest code right now, but I noticed this somewhere)
3) touch .digest.force
4) ../.bin/cronlist
Thanks! This is helpful, and I will man touch to find out more. I know that a better knowlege of unix would help, and I'm working on that! linda
At 1:37 PM -0400 10/6/00, Linda Wack is rumored to have typed:
Because what happens is that after a day or two has passed without any list activity, one or more people will post in the morning, but the digest is not delivered on schedule in the afternoon.
Actually, _this_ is the part I don't understand...the idea that there should be a "scheduled" time for the digest to be released. If you set the digest age to 20-22 hours, and run .bin/cronlist every six hours, you can be pretty confident that no message will sit longer than a day, without sending unnecessarily small issues. Of course, your issue will be released at whichever of the four runs is ~24 hours past the first message included, but then you'll have the same thing happen if it gets active and beats your size limit (which should _always_ be under 50k if there's a juno address in your list...). My point is, frankly, that those who subscribe to the interactive version get their mail immeidately, and those who subscribe to the digest version _expect_ the mail to be delayed. So what reason could there be for mandating a 2:00pm release every day, needed or not? As an aside (and not to you directly since you get it), the one thing I've noticed people have trouble grasping about SmartList is that the digest age clock starts ticking not when the last digest is released, but when the first message comes in _after_ that digest is released. Maybe this could be made clearer in the documentation in a future version?
I'm not sure that this one is necessary because I believe that flush_digests does this test and exits early if there is no digest.body
Irrelevant; why create the .digest.force file if it isn't necessary? (And again, using the method detailed above, you never _need_ to create that file, since you're pretty sure of no message being in the queue longer than a day.) Besides, the problem with creating .digest.force when there is no archive/latest/digest.body file is that the digest will end up being released on the next message no matter _what_ time it comes in (if you're determined to send it out at a specific time, then this is a bad thing, and if not, sending out what is in effect an interactive digest issue is a bad thing, making a lose-lose).
(I don't have access to the flush_digest code right now, but I noticed this somewhere)
Gad, I love responding to people who actually read the open-source _before_ asking their question. You ever need any help with anything dealing with SmartList, I'm your guy. Charlie
Charlie wrote, addressing Linda, | My point is, frankly, that those who subscribe to the interactive version | get their mail immeidately, and those who subscribe to the digest version | _expect_ the mail to be delayed. So what reason could there be for mandating | a 2:00pm release every day, needed or not? Linda's original question left me wondering whether perhaps she wants to send a null digest (to serve as a "no articles today" notification to digest-mode members) whenever twenty-four hours pass without a digest issue because there have been no submissions.
At 6:55 PM -0400 10/6/00, David W. Tamkin is rumored to have typed:
Linda's original question left me wondering whether perhaps she wants to send a null digest
Urgh...I didn't think about that. It might be an interesting exercise to write (you'd need to replicate the functions of digest in writing a new digest.header, probably touching a blank digest.body, as well as manually manipulating the digest number and other stuff I've probably forgotten), but seems kinda overkill. I mean, wouldn't it be easier to simply send a note to the distribution list through the cron job's shell script than to try to kludge SmartList to send this notification, if one were really determined to do it? ("Sorry, kids, no one had anything intelligent to say today.") Besides, one could assume that those subscribed to a digested mailing list would _expect_ irregular deliveries as part of the package - multiple issues per day when things are hopping, none some days when things aren't. If they _don't_ understand this, maybe they should be subscribed to the interactive version of the mailing list instead. (Mind you, this coming from a guy who inherited a mailing list that is digest-only...) And _this_ leads us to one of my favorite topics; how much we're going to coddle our subscribers simply because they are new to the Internet and mailing lists. (An example is putting the [list name] in every subject so they can easily filter, when if they bothered to read the manual that comes with their mail client they'd realize they could filter just as easily on the X-Mailing-List: header field and survive quite nicely without it. Or setting the Reply-To: header field because they don't know how to Reply-To-All as another example. "I got a million of 'em...") Is there any justification for telling subscribers there hasn't been any activity for the last 24-hours? Charlie
Charlie chiseled, | Besides, one could assume that those subscribed to a digested mailing list | would _expect_ irregular deliveries as part of the package - multiple issues | per day when things are hopping, none some days when things aren't. I have found that sometimes digest-mode subscribers get antsy; maybe not after twenty-four hours but certainly after seventy-two. Was there an issue that failed to reach them, or which a person with whom they share the email address (with so many free webmail and popmail servers and five screen names per AOL account one would think that nobody need share an address any more, but people still do) see it first and delete it? After all, some of them choose digest mode specifically because issues are numbered and they can be sure whether they're getting them all. (There also are mailing list packages that number the articles.) They will ask, and you can always instruct them to check the archives if there is a digest-mode archive. If the archives carry only individual messages, one thing I found that worked was a mailback command to the -request address that returns the volume num- ber, issue number, and timestamp of the most recent digest, plus the number of articles since then that are queued for the next issue.
participants (4)
-
Charlie Summers -
David W. Tamkin -
Linda Wack -
Linda Wack