Closed (cannot reproduce)
Project:
Bot
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
19 Jul 2009 at 13:08 UTC
Updated:
3 Jan 2011 at 15:31 UTC
Jump to comment: Most recent file
Comments
Comment #1
morbus iffoOoOOh, excellent!
Comment #2
kurkuma commentedGood job jonhattan!
Comment #3
morbus iffI'm curious - can we get rid of bot_start.php entirely by moving to a dependency on Drush? Can the 'start' command handle the loading of the IRC library, and make Drush the forever-running process?
Comment #4
jonhattanMy first attempt was to just include bot_start.php in the child code and it didn't worked. So I used the function pcntl_exec that allows to exec an external process by replacing current one.
Now I just tried moving bot_start.php's code to a function in bot.drush.inc and slightly modifying the ARGV code. The error is the same... Warning: MySQL server has gone away... I've also trying removing the bootstrap as drush already has bootstrapped drupal... same error.
Its weird but when I commented out
require_once('Net/SmartIRC.php');the mysql error dissapeared... if I move the require after the first connection to mysql (db_query('SET SESSION wait_timeout = %d', 24*60*60);) that query doesn't raise the error... but next ones do it. Any idea ?EDIT: it is just a problem of milliseconds. Mysql will fail anyway.... once the parent process (drush) ends its execution. bootstraping drupal again does not solve it.
So I think that to drop bot_start.php completely --if possible-- requires more knowledge about drush internals a/o process handling with php.
Comment #5
Jackinloadup commentedShould this file be placed the bot module?
Comment #6
jonhattanyes. It must be placed in the bot folder
Comment #7
jonhattanI've revisited the code to make some little changes. No functionality added / changed. I've commited it to my cvs sandbox in order to let me have the code more at hand and track changes.
http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/jonhattan/d...
Comment #8
jonhattanFYI: I've updated the code to work with drush 3.x
Comment #9
Gurpartap Singh commentedI wouldn't want to depend on drush. I don't use it on my servers, yet.
But it's definitely worth to use it when you have drush, since the "site" part is understood by drush itself.
Comment #10
frankcarey commentedAny chance this get's committed soon?
Comment #11
dave reidThe code in the sandbox needs work. If you do not have bot.module enabled, you can no longer run drush commands. We need to remove the bot_drush_init() check and use proper command dependencies.
Comment #12
q0rban commentedSubscribe.. this would be great, although for some reason it doesn't respect drush's --uri
Comment #13
q0rban commentedHere's a simplified version based on the request in #3 that basically moves everything to a drush command.
One thing I was running into with my version of Net_SmartIRC is that Net_SmartIRC::nreplycodes is set from $_GLOBALS, which may or may not actually be populated. It took me a while to figure out why my bots were just hanging, but without nreplycodes, the irc object never knows that the bot has successfully logged in. This is fixed in this patch as well.
Comment #14
q0rban commentedUpdated patch with a few minor tweaks. I've got it running on a site with
So far so good.
Comment #15
q0rban commentedAdding commands for stopping, querying status, and resetting status.
Comment #16
sirkitree commentedThis worked absolutely perfectly for me. Couldn't get our bot started, kept say 'job finished' and no bot in the chat room. updated to 1.x-dev, applied this patch, ran the
> nohup drush bot-start &command and it started right up. Major improvement from having to write that other long-ass command to get the bot started. Thanks q0rban!Comment #17
sirkitree commentedJust a note of a few things I found useful.
I ran into a problem where I incorrectly stopped the bot and it was stuck in the 'disconnecting' status. I was able to resolve this by using the reset-status command.
Then
Comment #18
danneb commentedgreat, thanks :D
Comment #19
slip commentedawesome! works for me. Just make sure you're running at least Drupal 6.16 because of the locking code.
Comment #20
morbus iffDrush integration committed to 7.x-dev (thanks jonhattan, q0rban, sirkitree)!
Comment #21
q0rban commentedI think drush may have a memory leak, as our bots end up dying after so many days, with output stating that memory could not be allocated. I'm thinking we may need to use drushd for this, so that the process is restarted as soon as memory reaches a certain threshold.
Comment #22
morbus iffq0rban: could you give me the exact error message? You've confirmed this doesn't happen if you use bot_start.php? I've had no similar problems on Druplicon running under Drush, and I can't actually see how it would be Drush's fault… once Drush gets to the $irc->listen() stage (i.e., within 30 seconds of issuing bot-start), no other part of Drush is ever run - it's just bot.module and the IRC library after that. As for bot restarting, take a look in scripts/ (under the d7 branch) - there's a bot_check.sh script in there that'll keep the bot alive.
Closing this - make a new issue to talk this over.
Comment #23
q0rban commentedNo problem. Here you go:
#1013458: drushd patch for 6.x