Posted by jonhattan on July 19, 2009 at 1:08pm
| Project: | Bot |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (cannot reproduce) |
Issue Summary
Attached is a drush.inc file that exposes following commands:
drush bot start
drush bot stop
drush bot restart
drush bot status
Bot is daemonized upon start and a pid file is stored at $SITE/bot.pid
| Attachment | Size |
|---|---|
| bot.drush_.inc_.txt | 5.02 KB |
Comments
#1
oOoOOh, excellent!
#2
Good job jonhattan!
#3
I'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?
#4
My 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.
#5
Should this file be placed the bot module?
#6
yes. It must be placed in the bot folder
#7
I'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...
#8
FYI: I've updated the code to work with drush 3.x
#9
I 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.
#10
Any chance this get's committed soon?
#11
The 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.
#12
Subscribe.. this would be great, although for some reason it doesn't respect drush's --uri
#13
Here'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.
#14
Updated patch with a few minor tweaks. I've got it running on a site with
> nohup drush bot-start &So far so good.
#15
Adding commands for stopping, querying status, and resetting status.
#16
This 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!#17
Just 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.
drush bot-reset-statusThen
nohup drush bot-start 
great, thanks :D
#19
awesome! works for me. Just make sure you're running at least Drupal 6.16 because of the locking code.
#20
Drush integration committed to 7.x-dev (thanks jonhattan, q0rban, sirkitree)!
#21
I 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.
#22
q0rban: 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.
#23
No problem. Here you go:
#1013458: drushd patch for 6.x