Thank you for showing me how to do it. First of all, the messages that appear in journalctl -f are located below.
I have both a Jetson Nano imx327 camera and a Jetson Xavier NX imx327 camera, but I only see this message on the Xavier NX camera.
Feb 16 00:24:58 linux kernel: camera_common_mclk_enable 864 mclk_init_rate : 37125000
Feb 16 00:24:58 linux kernel: imx327 2-001a: imx327_power_on: turned on mclk
Feb 16 00:24:58 linux kernel: imx327_power_on 481
Feb 16 00:24:58 linux kernel: imx327_power_on 487
Feb 16 00:24:58 linux kernel: imx327 2-001a: imx327_power_on: pwdn set to 1
Feb 16 00:24:58 linux kernel: imx327 2-001a: imx327_power_on: powered on
Feb 16 00:24:58 linux kernel: imx327_set_gain 275 val ; 3
Feb 16 00:24:58 linux kernel: imx327_set_exposure 373 val ; 29999
Feb 16 00:24:58 linux kernel: imx327_set_frame_rate 310 val ; 30000001 frame : 1124
Feb 16 00:25:01 linux kernel: **tegra194-vi5 15c10000.vi: no reply from camera processor**
Feb 16 00:25:01 linux kernel: **tegra194-vi5 15c10000.vi: uncorr_err: request timed out after 2500 ms**
Feb 16 00:25:01 linux kernel: tegra194-vi5 15c10000.vi: err_rec: attempting to reset the capture channel
Feb 16 00:25:01 linux kernel: tegra194-vi5 15c10000.vi: err_rec: successfully reset the capture channel
Feb 16 00:25:01 linux kernel: [RCE] WARNING: t194/vi5.c:459 [vi5_channel_disable] "ch 35 ABORT trial# 2/5 unsuccessful"
Feb 16 00:25:02 linux kernel: tegra194-vi5 15c10000.vi: corr_err: discarding frame 61312, flags: 134, err_data 512
Feb 16 00:25:02 linux kernel: tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 112, err_data 14680672
Feb 16 00:25:02 linux kernel: tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 38, err_data 160
Feb 16 00:25:02 linux kernel: tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 160, err_data 160
Thanks for the information provided, however only the log you provided is not enough to figure out the issue. In general it seems that main cause of your empty raw files is that you are not able to capture frames successfully in the first place, but there are many causes for this based on the log you provided.
Can you please provided the V4L2 trace log output as indicated in my previous answer?