its icon indicating copy to clipboard operation
its copied to clipboard

GCBULK dies all the time

Open eswenson1 opened this issue 2 years ago • 6 comments

On ES, the console log is littered with:

TOP LEVEL INTERRUPT 1,,0 DETACHED JOB # 12, USR:PFTHMG GCBULK 16:54:06

messages. I've never seen this daemon stay up. Is there some special configuration that needs to be done? Is it useful? If so, can it be made to stay up?

eswenson1 avatar Nov 11 '21 19:11 eswenson1

Running GCMAIL interactively (each time I've tried) seems to have no issues. It reads the .mail. directory and checks each entry for the FN1 of OSTATS, then does some checks to decide whether to reap it it is. When it gets to the end of the directory it does a .logout 1, as it should. I don't see why it should fail.

eswenson1 avatar Nov 11 '21 19:11 eswenson1

Ah. It appears to die on a .lose, because of the non-existence of a .BULK. directory. I guess this is a reasonable reason for failure.

eswenson1 avatar Nov 11 '21 19:11 eswenson1

But I don't really know why this didn't fail for me when I ran it interactively.....

eswenson1 avatar Nov 11 '21 19:11 eswenson1

I suspect GCMAIL is working and GCBULK is not. Because I interactively ran GCMAIL (JNAME was GCMAIL), that worked for me, but had I used a JNAME of GCBULK, it would have failed just like the DRAGON deaemon.

eswenson1 avatar Nov 11 '21 19:11 eswenson1

Isn't this related to #2097 since it deals with bulk email (mailing lists etc). Don't add the link by default, just if you want to deal with bulk email?

bictorv avatar Jun 30 '22 07:06 bictorv

GCBULK is dying because the .BULK. directory doesn't exist. We shouldn't create the link in the build if we don't create the directory (and protect against its getting deleted by adding a -read- -me- file.

eswenson1 avatar Sep 16 '23 15:09 eswenson1