여러모로 http://dev.textcube.org/ticket/1041 이런 식의 보완이 필요할 듯 싶긴 하네요.

coolengineer 작성:

Nabi 작성:

그렇군요. cronlog.txt를 확인해 봤더니 역시 주기적인 작업이라고 보기엔 너무 텀이 기네요.
업데이트 전까진 꾸준히 20-30분 내외정도로 작업을 했는데 말이죠..ㅠㅠ

혹시, 로그가 공개할 수 있는 정도면 이전과 이후의 referer에 해당하는 것을 알고 싶어서 그러는데,
올려주실수 있나요?

일부분만 빼서 올렸습니다. 1일까진 괜찮다가 2일째부터 그렇다는..
어제 제가 그동안 차단했던 봇들을 풀어서 그런지 오늘부턴 그래도 점차적으로 회복하는거 같기도 하구요...
일단 두고 보겠습니다.

아마.. robots.txt 작업을 하신듯하네요. 이전 로그를 보니 주 동력원이 검색엔진 로봇이 긁어가는 robots.txt 였습니다.

Nabi 작성:

그렇군요. cronlog.txt를 확인해 봤더니 역시 주기적인 작업이라고 보기엔 너무 텀이 기네요.
업데이트 전까진 꾸준히 20-30분 내외정도로 작업을 했는데 말이죠..ㅠㅠ

혹시, 로그가 공개할 수 있는 정도면 이전과 이후의 referer에 해당하는 것을 알고 싶어서 그러는데,
올려주실수 있나요?

일부분만 빼서 올렸습니다. 1일까진 괜찮다가 2일째부터 그렇다는..
어제 제가 그동안 차단했던 봇들을 풀어서 그런지 오늘부턴 그래도 점차적으로 회복하는거 같기도 하구요...
일단 두고 보겠습니다.

그렇군요. cronlog.txt를 확인해 봤더니 역시 주기적인 작업이라고 보기엔 너무 텀이 기네요.
업데이트 전까진 꾸준히 20-30분 내외정도로 작업을 했는데 말이죠..ㅠㅠ

혹시, 로그가 공개할 수 있는 정도면 이전과 이후의 referer에 해당하는 것을 알고 싶어서 그러는데,
올려주실수 있나요?

Nabi 작성:

Creorix 작성:

아마 쿨엔님이 만드신 poor man's cron이 조건에 맞는 방문자가 있어야 동작하기 때문에 주기가 정확하지는 않을겁니다 ^^

아! 그런건가요..'ㅁ'
그런데 그러기엔 MMS를 보낸후 2시간이 넘게 흘러도 검사를 하지 않으니..흠.. -_-;;;
뭔가 문제가 있는거 아닐까요... 업데이트 전엔 이 정도까진 아니었는데 말이죠.

현재 동작 방식은 http://dev.textcube.org/ticket/1041 에 나와 있는 대로 Referer 없이 URI 요청이 들어왔을 경우 주기적인 작업을 실행하는 방식입니다. (로봇이나 주소를 직접 쳐서, 혹은 즐겨찾기에서 방문한 경우 등이 되겠지요. 수동 수집은 잘 되는 것을 보니 문제가 있다면 cron 문제일 텐데 어떻게 확인할 수 있는 방법이 없을까요 쿨엔님?

그것이..

cache/cronlog.txt

에 얼마만에 한번씩 주기적인 작업을 위해 애썼나를 알 수 있는 방법이 있습니다. 어떤 URL 요청 끝에 시도한것인지도 알 수가 있습니다.

http://dev.textcube.org/ticket/1041

와 같이 진행해야할 듯합니다.

아마 쿨엔님이 만드신 poor man's cron이 조건에 맞는 방문자가 있어야 동작하기 때문에 주기가 정확하지는 않을겁니다 ^^

아! 그런건가요..'ㅁ'
그런데 그러기엔 MMS를 보낸후 2시간이 넘게 흘러도 검사를 하지 않으니..흠.. -_-;;;
뭔가 문제가 있는거 아닐까요... 업데이트 전엔 이 정도까진 아니었는데 말이죠.

원래 주기적인 간격으로 해당 메일에서 메일을 읽고 검사를 하는데 로그파일을 봐도 그렇고 실제로 테스트를

해봐도 그렇고 주기적인 간격으로 읽어 오는 기능이 작동을 안하네요. 몇시간이 지나도 묵묵부담...;

그래서 강제로 수동으로 '시험하기'를 눌러 하면 잘 되구요.

참고로 전 통신사는 KTF에 메일은 야후입니다. 확인 좀 부탁드려요~