augh, workers

[kareila]

I am having massive amounts of fail trying to do anything on my dreamhack involving crossposting or importing. I'm trying to test a pretty simple bugfix that just involves viewing a crossposted entry and a non-crossposted entry and looking for different text strings on each.

I can't get the crossposter to work. First the worker isn't running, so I fix that, then the date is out of order on the destination journal, so I fix that, then the password is invalid, so I fix THAT, then... nothing.

Then I deleted the crosspost account and... it won't let me create another one (0/0). Erk.

So I decided to see if importing my LJ would work somehow, and that isn't doing anything either. It's been stuck at the verifying user/pass step for... almost half an hour now.

Am I doing something stupid, or has LJ blocked the dreamhack machine (and if so, how to get the option to crosspost to/import from DW working?) or... is there anything else I'm missing here?

Alternatively, can someone else test my fix for bug 2531 so I can stop worrying about it?

SO FRUSTRATED.

Comments

[exor674]

You wanna hop on IRC so you can test on my box and we can coordinate with patch applied / unapplied, etc?

[kareila]

Can I take you up on that in 20-30 min? Waiting for husband to get home to take over with kids. Thanks!

[exor674]

Sure!

[kareila]

My patch works! NOTHING ELSE DOES.

[mark]

Did you get this sorted? :)

[kareila]

Not really, but I have moved on to other things!

[mark]

The only thing I was going to have you do was run the workers manually, w/o the worker-manager.

Both of these:
bin/worker/content-importer-verify -v
bin/worker/content-importer -v

And of course:
bin/worker/xpost -v

Then you have to run this every time you have a change in the imports, i.e., to do the scheduling:

bin/worker/import-scheduler

It exits when it's done, so you have to re-run it. I usually stick it in a loop:

while true; do sleep 10 && bin/worker/import-scheduler; done

Then it runs every 10 seconds and I don't have to think about it.

This doesn't run any of the jobs to send ESN messages though, so sometimes since status is sent that way, you then have to run the standard filter, esn, etc jobs.

[kareila]

Hmm, would a reasonable hybrid approach be to comment out the xpost and importer jobs in workers.conf, run those in verbose mode manually as you suggest, and let the others run normally via worker-manager?

[mark]

Yep, I do that. I have my own custom etc directory that doesn't get overridden and I put in workers.conf with whatever I don't care to mess with, and then run manually everything else.