Happy Birthday email outta control...

[TruckZMod]

Some of my folks have been reporting that they are getting a dozen e-mails on their birthdays. I've confirmed that this is happening. I've deleted the process of sending them (I think) through AdminCP ==> Scheduled Tasks ==> Shedule Task Manager, but I got one after that so I rebooted the server. I modified my birthday to today's date and am waiting to see if I get another one soon. What other process in the software or on the server may be contributing to the replication of this process? And is there a way I could'a fixed it without deleting it? Thanks!

[Steve Machol]

This is definitely a server and/or ISP issue. Theere really isn't anything you can do from the vB end except to make sure you are running the original vB files.

[TruckZMod]

Still getting 'em...

Any idea which vbulletin files or databases I might sniff into to see what the heck is going on here? I would suspect the server or the software before blaming the ISP because each of the emails contains new ID numbers...

Thansk!

[Steve Machol]

This isn't a vB issue (again assuming you are using the original code), and unfortunately I do not know where to look in the server. You could check the mail queue on the server to see if there is anything unusual.

[conqsoft]

You didn't change the birthday task to run every hour did you?

[TruckZMod]

This isn't a vB issue (again assuming you are using the original code), and unfortunately I do not know where to look in the server. You could check the mail queue on the server to see if there is anything unusual.

Sorry Steve, I beg to differ with you. Please take a close look at the mail headers below:

Message-ID: <200508052057.**********@www.truckz.com>
X-Mailer: vBulletin Mail via PHP

Do you see that nasty little tag in there which says *vBulletin Mail*? All the programming is pretty much original, I had no reason to alter anything related to e-mail functions.

I kept a steady watch on the server's e-mail queue before writing you originally. This is what that says...
No mail messages are currently queued for delivery

And, I don't see any lingering cron jobs in the system which would account for the outbound e-mail. I'm into year three of using vBulletin on this site and this is a relatively new problem ... and I'm using version 3.0.8. Do you think maybe you could think just a little bit more about possible solutions or escalate to another programmer before dismissing it so quickly again?

Thanks!

[Steve Machol]

Honestly there is nothing in the default vB code that would cause vB to send out multiple emails like this, again assuming you have not installed any hacks (which you haven't clarified) or you didn't change the Birthday Scheduled Task as conqsoft mentioned.

Nonetheless I'll point your thread out to the other staff members, although there isn't anything keeping them from reading and responding to it now.

[TruckZMod]

Thanks -- I do appreciate that. As I mentioned in the first post in this thread, I deleted the Birthday Scheduled Task -- didn't modify it. I think it may be necessary to outright disable this specific process on my box ... but other than deleting the task, I really don't want to go in there with a chainsaw when modifying one or two lines in a php file will help me get past this.

Again -- thanks. I don't know what's gone wrong -- I just know that for whatever reason it has gone wrong. If I knew where to chase the bug outta the system, I'd do it. : )

[Zachery]

Had you modifyed the time to run any of your scheudled tasks? There is no reason to be getting multiple birthday emails short of a system time error or you are forcing your tasks to run more than once a day.

And the "vBulletin Mail" issue is only a tag we add in our mail class which is baiscly php's mail class.

[TruckZMod]

Hi Zach -- I don't believe I've modified any of the scheduled tasks. I'll check real quick to see if any are running more than once per day...

Okay, here's what I have. Again -- understand, I don't remember modifying any of these...

m h D M DoW Title Next time
40 * * * * Hourly Cleanup #2 08-07-05 08:40 AM
45 * * * * User Promotions 08-07-05 08:45 AM
56 * * * * Thread Views 08-07-05 08:56 AM
05 * * * * Hourly Cleanup #1 08-07-05 09:05 AM
10 * * * * Attachment Views 08-07-05 09:10 AM
15 * * * * Restore Temporarily Banned Users 08-07-05 09:15 AM
00 0 * * * Subscriptions 08-07-05 11:00 PM
00 0 * * * Daily Statistics Log 08-07-05 11:00 PM
02 0 * * * Daily Digest08-07-05 11:02 PM
03 0 * * * Activation Reminder Email08-07-05 11:03 PM
30 0 * * Mon Weekly Digest 08-08-05 11:30 PM

Do any of those jump off the page as being potential problems to you? If any of these look odd to you, please tell me which to change. Thanks! : )

[TruckZMod]

I'm disappointed that noone got back to me on this, especially after I posted the Sheduled Task manager for my server above.

I have managed to get things back to some semblance of sanity after exploring the files in the /forums/includes/cron directory, and comparing them to the originals in my upload directory. Two had been mysteriously renamed --> attachmentviews.php and birthday.php. I'm sure you can understand the repurcussions of this error. If someone would have suggested I check files in the /forums/includes/cron directory earlier, I could have solved the problem much sooner.

Ultimately, this was not a vBulletin or Jelsoft program error ... and the origins of this problem rest squarely on my shoulders because I am ultimately responsible for what goes on inside the server. But, I believe this matter was dismissed too quickly as, "definitely a server and/or ISP issue." The suggestion was made that we check to make certain, "...you are running the original vB files." But, I wasn't pointed in the right general direction for where to look for the potential problem files -- and that was provided by the very nature of the problem description. I had to learn much more than I cared to learn about the software's operation and coding to ultimately track this problem down -- on my own.

I've looked in the mirror folks and taken ultimate responsibility for what went wrong. I hope customer service makes a serious self-examination at what it might have done to assist a (three year and multiple license) customer resolve this matter in a much more timely manner -- without a rush to dismiss potential responsibility for the problems. I've seen it happen in other threads while hunting resolutions to similar problems and possible solutions -- an eagerness or quickness to say, "It ain't our fault!", instead of suggestions on where one might look to find the solutions they need.