fix(commands): limit journal_logs output to specified number of lines using head instead of --lines

[umglurf]

Journalctl with --lines combined with other filters such as --since filters lines first, then applies filtering logic, ref systemd/systemd#26669
This makes the journalctl tool not work as intended, as the agent is not able to query logs from a given time.
This PR replaces --lines with using head, making it possible to query logs from a given timestamp.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Flag	Coverage Δ
unittests	97.40% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/linux_mcp_server/commands.py	89.09% <ø> (ø)
tests/tools/test_logs.py	100.00% <100.00%> (ø)

... and 3 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[owtaylor]

Thanks for trying linux-mcp-server out and contributing!!

Digging into this - before systemd/systemd#26669 (system 254 I think, RHEL 8 is 252, RHEL 9 257) behaved pretty badly with -n and --since/--until.

• journalctl -n 10 - last 10 lines
• journalctl -u <UNIT> -n 10 - last 10 lines for unit
• journalctl --since <TIME> -n 10 - first 10 lines after time
• journalctl -until <TIME> -n 10 - nothing

The current behavior where -n 10 is just like | tail -n 10, but more efficient seems a lot better. Except that --since is rather surprising, if you (or the model) is trying to get the events right after a timestamp.

I'd think about two things:

• Should we try to emulate the newer behavior for older systemd, so the output is consistent?
• Should we expose -n +10 in some fashion?

But I don't think I'd want to go with the approach here - always providing the first N lines (for any filters or no filters) is surprising, and probably not as useful as getting the last N lines.

Can you share (at a high level) what prompt you used and what the model was trying to do so that we can better understand the use case?

[umglurf]

Thanks for trying linux-mcp-server out and contributing!!

Digging into this - before systemd/systemd#26669 (system 254 I think, RHEL 8 is 252, RHEL 9 257) behaved pretty badly with -n and --since/--until.

* `journalctl -n 10 ` - last 10 lines

* `journalctl -u <UNIT> -n 10 ` - last 10 lines for unit

* `journalctl --since <TIME> -n 10 ` - first 10 lines after time

* `journalctl -until <TIME> -n 10 ` - nothing

The current behavior where -n 10 is just like | tail -n 10, but more efficient seems a lot better. Except that --since is rather surprising, if you (or the model) is trying to get the events right after a timestamp.

I'd think about two things:

* Should we try to emulate the newer behavior for older systemd, so the output is consistent?

* Should we expose `-n +10` in some fashion?

I think that would be very useful. The description for the line parameter just says Number of log lines to retrieve, it does not say in which direction this is done and as described in my case below and the reason for this PR, I think we need this possibility.

But I don't think I'd want to go with the approach here - always providing the first N lines (for any filters or no filters) is surprising, and probably not as useful as getting the last N lines.

Can you share (at a high level) what prompt you used and what the model was trying to do so that we can better understand the use case?

I was asking the the agent to find out why a given service had stopped around a given time the day before. It then correctly sent the correct since parameter set to the start time of the incident, but because the lines parameter is mandatory and behaves the way it does, it consistently was only able to get recent logs, and not from the time of the issue. With the current behavior, an agent can only retrieve historical logs by retrieving potentially thousands of lines, which would fill up the context window, unless run in some code as tool environment with access to filtering the output through code before returning to the agent.