Live-logging doesn't work after recent change (#52)

[mchal]

Hi,

I've just upgraded cronmaster and live-logging stopped working.

My assumption is that it's related to #52

When I kick-off the process manually in Chrome, in Network inspection I can see multiple calls to the api with results:

200: {"status":"failed","content":"","message":"Log file not yet created"}

and then after awhile (I'm assuming when the process is finished):

404: {"error":"Running job not found"}

On the frontend, regardless if the api returns 200 with status: "failed", or 404 all I see is:

Waiting for job to start...

Logs will appear here in real-time.

I can confirm that the log is in fact created for this job:

root@wth:/mnt/user/appdata/cronmaster/data/logs/d03r-xj7s# ls -la
total 4
drwxrwxrwx 1 root root  45 Nov 20 09:52 ./
drwxrwxrwx 1 root root  31 Nov 19 17:59 ../
-rw-rw-rw- 1 root root 330 Nov 20 09:52 2025-11-20_09-52-36.log

Hope this helps.

[ScrumpyJack]

Confirmed. Could be from #61 API now requires authn

[fccview]

That is very interesting.
Everything works well on my instance, would you be able to move out the logs folders and see if allowing cronmaster to re-creating them fixes the issue?

@ScrumpyJack I don't think it has to do with the api as I don't have one set on my instance right now and it still works well.

I am pretty confident is related to #52 as the Running job ID has been added as a fix to these specific issues, and I think it's not backward compatible, although it really should be 🤦

edit

Another way to test this without removing the folder is to disable logging, manually update the job ID in crontab and re-enabling logging, then run the job.

[mchal]

within docker, I've renamed logs to logs_old and run the job manually.

Still the same outcome on the frontend.
I can confirm all folders and log file for the job are there:

root@314fbce17faf:/app/data# ls -la
total 8
drwxr-xr-x 1   99 users  126 Nov 20 14:00 .
drwxr-xr-x 1 root root   132 Nov 20 07:30 ..
-rwxr-xr-x 1 root root  1940 Nov 19 17:57 cron-log-wrapper.sh
drwxrwxrwx 1 root root    31 Nov 20 14:00 logs
drwxrwxrwx 1 root root    31 Nov 19 17:59 logs_old
-rw-r--r-- 1 root root  1100 Nov 20 14:00 running-jobs.json
drwxr-xr-x 1 root root    35 Nov 18 02:54 sessions
root@314fbce17faf:/app/data# cd logs
root@314fbce17faf:/app/data/logs# ls -la
total 0
drwxrwxrwx 1 root root   31 Nov 20 14:00 .
drwxr-xr-x 1   99 users 126 Nov 20 14:00 ..
drwxrwxrwx 1 root root   45 Nov 20 14:00 d03r-xj7s
root@314fbce17faf:/app/data/logs# cd d03r-xj7s/
root@314fbce17faf:/app/data/logs/d03r-xj7s# ls -la
total 4
drwxrwxrwx 1 root root  45 Nov 20 14:00 .
drwxrwxrwx 1 root root  31 Nov 20 14:00 ..
-rw-rw-rw- 1 root root 705 Nov 20 14:01 2025-11-20_14-00-45.log

---

Change

I've updated the job-id in crontab to test-logs and result is slightly different:
On the frontend it looked the same:

but the api now returned:

{
  "status": "running",
  "content": "",
  "message": "Log directory not yet created"
}

and can confirm - this directory is not there! Strange as previously moved folders were recreated for the old job.

Just to confirm - I'm running this within docker; Docker runs with privileged: true

[fccview]

Thank you, all these logs really help.
Can you try to sudo chown -R 1000:1000 data to change the data folder permissions to the host user?

I doubt that'll work but I need to exclude everything before I start changing things, as I said I can't replicate this 🥲

[mchal]

Apologies! I've renamed job-id wrongly (only in the comment in crontab); had to update the job-id for cron-log-wrapper.sh process.

Folder and logs are there now, but frontend still returns nothing.

Permissions look fine (folder & logs are created after all), read permission is for everyone (777 for the folder, 666 for log file), but just in case I've followed your suggestion and changed to: 1000:1000, root:root, nobody:users, nextjs:nodejs.

Cronmaster can read the folder, otherwise it wouldn't be able to see that folder wasn't there before, and now is there.
Not sure why it cannot read content of the folder now (folder got read permission for everyone) - it was working fine in 1.5.0 as far as I remember (yesterday).

---

What I've noticed as well is that checking logs on the frontend returns nothing, even though logs are there:

(within docker)

root@314fbce17faf:/app/data/logs/test-logs# echo "test" >testing 
root@314fbce17faf:/app/data/logs/test-logs# cd ..
root@314fbce17faf:/app/data/logs# ls -lRa
.:
total 0
drwxrwxrwx 1 nextjs nodejs  52 Nov 20 14:28 .
drwxr-xr-x 1 nextjs nodejs 145 Nov 20 14:26 ..
drwxrwxrwx 1 nextjs nodejs 220 Nov 20 14:26 d03r-xj7s
drwxrwxrwx 1 root   root    29 Nov 20 14:37 test-logs

./d03r-xj7s:
total 24
drwxrwxrwx 1 nextjs nodejs  220 Nov 20 14:26 .
drwxrwxrwx 1 nextjs nodejs   52 Nov 20 14:28 ..
-rw-rw-rw- 1 nextjs nodejs 1594 Nov 20 14:02 2025-11-20_14-00-45.log
-rw-rw-rw- 1 nextjs nodejs 1594 Nov 20 14:07 2025-11-20_14-06-01.log
-rw-rw-rw- 1 nextjs nodejs 1594 Nov 20 14:22 2025-11-20_14-20-09.log
-rw-rw-rw- 1 root   root   1594 Nov 20 14:24 2025-11-20_14-22-28.log
-rw-rw-rw- 1 root   root   1594 Nov 20 14:26 2025-11-20_14-24-32.log
-rw-rw-rw- 1 root   root   1368 Nov 20 14:28 2025-11-20_14-26-11.log

./test-logs:
total 4
drwxrwxrwx 1 root   root   29 Nov 20 14:37 .
drwxrwxrwx 1 nextjs nodejs 52 Nov 20 14:28 ..
-rw-rw-rw- 1 root   root    5 Nov 20 14:43 testing

Thank you for being so responsive!
I will keep investigating after work.

PS. Greetings from Bristol :)

[fccview]

Hey @mchal gonna also investigate after work a bit more :)

It baffles me that you can write to the folder but the UI doesn't see it, I must have messed up something when fixing the live stream but for some reason it just works for me 🤦

I'll go deep into it tonight.
And Bristol has indeed been my home for many years, alas I moved a year ago 😆

[mchal]

I made one small change - I've downgraded to 1.5.1 and no problems with live logs, although listing logs still returns nothing (I would expect to get log of the currently running job)
API returns:
{
"status": "running",
"content": "",
"newContent": "",
"logFile": "2025-11-20_15-01-52.log",
"isComplete": false,
"fileSize": 398,
"offset": 398
}

Will investigate this later.
Thank you

[mchal]

I might have something after reading a code, but apologies, I don't know react/next.js so might be totally wrong.

Not sure why I had initially an error Log file not yet created, but maybe I found something.

Sorry, a little bit chaotic, but hopefully I've explained clearly enough :)

---

If I understand correctly, whenever we run a job, a new record is created in a file running-jobs.json
The type of the record is RunningJob with logFileName being optional.

This is an example of a record in my json file:

{
    "id": "run-test-logs-1763653388910",
    "cronJobId": "test-logs",
    "pid": 616675,
    "startTime": "2025-11-20T15:43:08.917Z",
    "status": "failed",
    "logFolderName": "test-logs"
  }

and logFileName is missing.

In app/api/logs/stream/route.ts in a function GET you have this code:

cronmaster/app/api/logs/stream/route.ts

Line 27 in 4beb705

const job = getRunningJob(runId);

to get the job based on id.
Then

cronmaster/app/api/logs/stream/route.ts

Line 77 in 4beb705

if (job.logFileName) {

will always be false, because it's not set in RunningJob, and because of that this will be always true

cronmaster/app/api/logs/stream/route.ts

Line 90 in 4beb705

if (!latestLogFile) {

because latestLogFile is undefined and is never updated after initialising, so it will always fall back into this:

if (!latestLogFile || !latestStats) {
      return NextResponse.json(
        {
          status: job.status,
          content: "",
          message: "No log file found for this run",
        },
        { status: 200 }
      );
    }

Previously you were relying on the latest file in the log folder rather than logFileName in RunningJob and it was working fine, but I think you've noticed that this approach was working incorrectly, when a new file was created during the life of the running job in that folder.

If that is the root-cause of the problem, then not sure how come it was working on your end :)

Hope this helps!

[fccview]

hey @mchal
There's a fallback for logs created before the latest update which actually look for the log file if the fileName is not there (on line 90 on the same file)

It checks for the log folder and gets the latest logs created to be streamed.

My instance actually doesn't generate the running-jobs.json on legacy jobs that were created before I upgraded, which is why it's still working. I am not entirely sure why yours creates them without adding the right information, which is clearly the bug, so nice find.

Need to sort out dinner and then I'll deep dive into this issue as I am pretty sure I messed something up in the stream logic 🤦

[fccview]

Hey @mchal
I have done a bit of refactoring and I'd like you to try the latest :develop image (change :latest to :develop in your docker-compose.yml file).

If you could do two tests

1 - just give it a go right away, if it works all good!
2 - if it doesn't work can you replace the content of your running-jobs.json file with [] and give it another shot.

Let me know if this sorts it out for you (ideally i'd love for @ScrumpyJack to give this a try too, so i can have two people confirming on top of myself).

This seems to be an issue with how different systems handle datetime, as there's no way both me and ShadowTox (see issue #67 ) can run jobs just fine but you two can't. You were 100% correct, the logFileName was not being populated, and the fallback was failing for you due to whatever slight difference in docker environments we may have. That's my theory at least. Anyhow I have added a watcher that detects when a new log file appears (checking every 500ms for up to 15 seconds) and caches the filename directly in that json file. Now the API should be able to read the correct file immediately without timestamp comparisons.

[mchal]

Hey,
I'm running :develop now. Version in package.json is still 1.5.3, but I got extra option "Show last: 500 lines", so looks like I got new version.

• Without any changes - doesn't work
• with updated running-jobs.json with an empty array [] - doesn't work, but just to confirm - this is how json looked like after first run:

[
  {
    "id": "run-test-logs-1763666856206",
    "cronJobId": "test-logs",
    "pid": 969966,
    "startTime": "2025-11-20T19:27:36.214Z",
    "status": "running",
    "logFolderName": "test-logs"
  }
]

• extra scenario - I've deleted running-jobs.json - still doesn't work; file has been recreated with this content:

[
  {
    "id": "run-test-logs-1763667081207",
    "cronJobId": "test-logs",
    "pid": 975323,
    "startTime": "2025-11-20T19:31:21.214Z",
    "status": "running",
    "logFolderName": "test-logs"
  }
]

no logFileName in the json file

[fccview]

ok I am officially extremely confused by this 😆
would you be willing to share the command from your actual crontab -l (with wrapper included)
and a tree view of your folder structure?

I need to make sure there's nothing weird going on, you SHOULD see the file name now 🥲