On Periphery servers it's not clear where the logs are stored. The same holds for JSON files that are deserialized, e.g. in order to clone a git repo.
This is a bit annoying as I have two Periphery servers running the same periphery.config.toml and yet only one of them can clone git repositories successfully due to an http 422 unprocessable entity error which is caused by a missing entry in a JSON file that is nowhere to be found.
Better documentation would be much appreciated!
Originally created by @LevitateDilationEggbeater on GitHub (Jul 29, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/691
On Periphery servers it's not clear where the logs are stored. The same holds for JSON files that are deserialized, e.g. in order to clone a git repo.
This is a bit annoying as I have two Periphery servers running the same periphery.config.toml and yet only one of them can clone git repositories successfully due to an http 422 unprocessable entity error which is caused by a missing entry in a JSON file that is nowhere to be found.
Better documentation would be much appreciated!
I'm not sure what you mean with json files, nothing like that happens and perhaps you are misinterpreting an error. It sounds like periphery version might be out of date with core. Otherwise, please share the log you are seeing.
<!-- gh-comment-id:3130793598 -->
@mbecker20 commented on GitHub (Jul 29, 2025):
For docker container periphery, logs are handled by docker and found with docker logs command.
For systemd, logs are managed by systemd and accessible with systemctl status and journalctl.
See here for other file locations using systemd installer - https://github.com/moghtech/komodo/tree/main/scripts
I'm not sure what you mean with json files, nothing like that happens and perhaps you are misinterpreting an error. It sounds like periphery version might be out of date with core. Otherwise, please share the log you are seeing.
@LevitateDilationEggbeater commented on GitHub (Jul 29, 2025):
Thanks for the answer. That does help.
The error I received when trying to clone a repo ist as follows:
ERROR: failed to clone repo
TRACE:
1: 422 Unprocessable Entity
2: Failed to deserialize the JSON body into the target type: params.args: missing field `default_folder` at line 1 column 300
The version of Periphery is the same as on a second server where cloning works without issue. Nonetheless, I will later double check and reinstall the Periphery service. Is it necessary/recommended to also delete the service file or is forcing its recreation sufficient?
<!-- gh-comment-id:3130890396 -->
@LevitateDilationEggbeater commented on GitHub (Jul 29, 2025):
Thanks for the answer. That does help.
The error I received when trying to clone a repo ist as follows:
```
ERROR: failed to clone repo
TRACE:
1: 422 Unprocessable Entity
2: Failed to deserialize the JSON body into the target type: params.args: missing field `default_folder` at line 1 column 300
```
The version of Periphery is the same as on a second server where cloning works without issue. Nonetheless, I will later double check and reinstall the Periphery service. Is it necessary/recommended to also delete the service file or is forcing its recreation sufficient?
You don't need to mess with the service file or recreate it. Just upgrade the binary by running the install script again as either root or user (however your did it before)
<!-- gh-comment-id:3132465027 -->
@mbecker20 commented on GitHub (Jul 29, 2025):
You don't need to mess with the service file or recreate it. Just upgrade the binary by running the install script again as either root or user (however your did it before)
@LevitateDilationEggbeater commented on GitHub (Jul 30, 2025):
I did try that but the result is the same as before.
I run the service as root and I have also cloned the repo as root. The periphery service detects a build hash (because I clicked built to see what would happen) and a commit hash.
The error message I receive in all cases is the same the one outlined above.
ERROR: failed to clone repo
TRACE:
1: 422 Unprocessable Entity
2: Failed to deserialize the JSON body into the target type: params.args: missing field `default_folder` at line 1 column 300
The journalctl logs generate tons of ssh output which does not look very useful to me:
Jul 30 06:52:30 services sh[561016]: 2025-07-30T06:52:30.924048Z TRACE h2::codec::framed_write: queued_data_frame: false
Jul 30 06:52:30 services sh[561016]: in h2::codec::framed_write::FramedWrite::flush
Jul 30 06:52:30 services sh[561016]: in h2::proto::connection::poll
Jul 30 06:52:30 services sh[561016]: in h2::proto::connection::Connection with peer: Server
Jul 30 06:52:30 services sh[561016]: in h2::server::server_handshake
Jul 30 06:52:30 services sh[561016]: 2025-07-30T06:52:30.924101Z TRACE h2::codec::framed_write: flushing buffer
Jul 30 06:52:30 services sh[561016]: in h2::codec::framed_write::FramedWrite::flush
Jul 30 06:52:30 services sh[561016]: in h2::proto::connection::poll
Jul 30 06:52:30 services sh[561016]: in h2::proto::connection::Connection with peer: Server
Jul 30 06:52:30 services sh[561016]: in h2::server::server_handshake
<!-- gh-comment-id:3135086789 -->
@LevitateDilationEggbeater commented on GitHub (Jul 30, 2025):
I did try that but the result is the same as before.
<img width="506" height="235" alt="Image" src="https://github.com/user-attachments/assets/0ced1701-51e4-4360-a0e3-e2244951e755" />
I run the service as root and I have also cloned the repo as root. The periphery service detects a build hash (because I clicked built to see what would happen) and a commit hash.
The error message I receive in all cases is the same the one outlined above.
>
> ```
> ERROR: failed to clone repo
>
> TRACE:
> 1: 422 Unprocessable Entity
> 2: Failed to deserialize the JSON body into the target type: params.args: missing field `default_folder` at line 1 column 300
> ```
The journalctl logs generate tons of ssh output which does not look very useful to me:
```
Jul 30 06:52:30 services sh[561016]: 2025-07-30T06:52:30.924048Z TRACE h2::codec::framed_write: queued_data_frame: false
Jul 30 06:52:30 services sh[561016]: in h2::codec::framed_write::FramedWrite::flush
Jul 30 06:52:30 services sh[561016]: in h2::proto::connection::poll
Jul 30 06:52:30 services sh[561016]: in h2::proto::connection::Connection with peer: Server
Jul 30 06:52:30 services sh[561016]: in h2::server::server_handshake
Jul 30 06:52:30 services sh[561016]: 2025-07-30T06:52:30.924101Z TRACE h2::codec::framed_write: flushing buffer
Jul 30 06:52:30 services sh[561016]: in h2::codec::framed_write::FramedWrite::flush
Jul 30 06:52:30 services sh[561016]: in h2::proto::connection::poll
Jul 30 06:52:30 services sh[561016]: in h2::proto::connection::Connection with peer: Server
Jul 30 06:52:30 services sh[561016]: in h2::server::server_handshake
```
@LevitateDilationEggbeater commented on GitHub (Jul 30, 2025):
Issue resolved.
Sorry for causing such a stir. For some reason my core container got stuck at version v1.17.2 and I had to manually set the tag to the latest version. After updating everything works fine.
<!-- gh-comment-id:3135673300 -->
@LevitateDilationEggbeater commented on GitHub (Jul 30, 2025):
Issue resolved.
Sorry for causing such a stir. For some reason my core container got stuck at version v1.17.2 and I had to manually set the tag to the latest version. After updating everything works fine.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @LevitateDilationEggbeater on GitHub (Jul 29, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/691
On Periphery servers it's not clear where the logs are stored. The same holds for JSON files that are deserialized, e.g. in order to clone a git repo.
This is a bit annoying as I have two Periphery servers running the same periphery.config.toml and yet only one of them can clone git repositories successfully due to an http 422 unprocessable entity error which is caused by a missing entry in a JSON file that is nowhere to be found.
Better documentation would be much appreciated!
@mbecker20 commented on GitHub (Jul 29, 2025):
For docker container periphery, logs are handled by docker and found with docker logs command.
For systemd, logs are managed by systemd and accessible with systemctl status and journalctl.
See here for other file locations using systemd installer - https://github.com/moghtech/komodo/tree/main/scripts
I'm not sure what you mean with json files, nothing like that happens and perhaps you are misinterpreting an error. It sounds like periphery version might be out of date with core. Otherwise, please share the log you are seeing.
@LevitateDilationEggbeater commented on GitHub (Jul 29, 2025):
Thanks for the answer. That does help.
The error I received when trying to clone a repo ist as follows:
The version of Periphery is the same as on a second server where cloning works without issue. Nonetheless, I will later double check and reinstall the Periphery service. Is it necessary/recommended to also delete the service file or is forcing its recreation sufficient?
@mbecker20 commented on GitHub (Jul 29, 2025):
You don't need to mess with the service file or recreate it. Just upgrade the binary by running the install script again as either root or user (however your did it before)
@LevitateDilationEggbeater commented on GitHub (Jul 30, 2025):
I did try that but the result is the same as before.
I run the service as root and I have also cloned the repo as root. The periphery service detects a build hash (because I clicked built to see what would happen) and a commit hash.
The error message I receive in all cases is the same the one outlined above.
The journalctl logs generate tons of ssh output which does not look very useful to me:
@LevitateDilationEggbeater commented on GitHub (Jul 30, 2025):
Issue resolved.
Sorry for causing such a stir. For some reason my core container got stuck at version v1.17.2 and I had to manually set the tag to the latest version. After updating everything works fine.