) (sonic-net#23591)

### Description of PR
Fixes sonic-net#23562

#### Summary
The `place_marker_to_syslog()` method called `flush_rsyslogd()`
(`systemctl reload rsyslog`) immediately after writing the marker to
syslog. The reload briefly closes and reopens log files, which can race
with the marker message still sitting in rsyslog's internal buffer,
causing the marker to be silently dropped.

**Root cause:** PR sonic-net#22447 replaced `kill -HUP` with `systemctl reload
rsyslog` to avoid syslog message loss during the *previous* flush.
However, calling the reload *right after* writing a new marker creates a
new race — the just-written marker can be dropped during the reload's
file close/reopen cycle.

**Fix:** Flush rsyslog *before* writing the marker (to drain old
buffers), then after writing the marker, use a simple `time.sleep(2)`
instead of a reload to let rsyslog write the marker to disk naturally.

### Type of change
- [x] Bug fix

### Back port request
- [ ] N/A

### Approach
#### What is the motivation for this PR?
LogAnalyzer's `add_end_marker` action fails intermittently with
`RuntimeError: cannot find marker end-LogAnalyzer-... in
/var/log/syslog`, causing test failures across all platforms.

#### How did you do it?
Moved the `flush_rsyslogd()` call to *before* writing the syslog marker
and replaced the post-write flush with a 2-second sleep. This ensures:
1. Pre-existing buffered messages are flushed before the marker is
written
2. The marker itself is not disrupted by a concurrent rsyslog reload
3. rsyslog has time to naturally write the marker to disk

#### How did you verify/test it?
- Code review of the race condition timeline
- The fix eliminates the problematic pattern (write then immediate
reload) identified in the issue

---
> [!NOTE]
> This PR was generated with the assistance of an AI agent.

Signed-off-by: Ying Xie <[email protected]>

) (sonic-net#23591)

### Description of PR
Fixes sonic-net#23562

#### Summary
The `place_marker_to_syslog()` method called `flush_rsyslogd()`
(`systemctl reload rsyslog`) immediately after writing the marker to
syslog. The reload briefly closes and reopens log files, which can race
with the marker message still sitting in rsyslog's internal buffer,
causing the marker to be silently dropped.

**Root cause:** PR sonic-net#22447 replaced `kill -HUP` with `systemctl reload
rsyslog` to avoid syslog message loss during the *previous* flush.
However, calling the reload *right after* writing a new marker creates a
new race — the just-written marker can be dropped during the reload's
file close/reopen cycle.

**Fix:** Flush rsyslog *before* writing the marker (to drain old
buffers), then after writing the marker, use a simple `time.sleep(2)`
instead of a reload to let rsyslog write the marker to disk naturally.

### Type of change
- [x] Bug fix

### Back port request
- [ ] N/A

### Approach
#### What is the motivation for this PR?
LogAnalyzer's `add_end_marker` action fails intermittently with
`RuntimeError: cannot find marker end-LogAnalyzer-... in
/var/log/syslog`, causing test failures across all platforms.

#### How did you do it?
Moved the `flush_rsyslogd()` call to *before* writing the syslog marker
and replaced the post-write flush with a 2-second sleep. This ensures:
1. Pre-existing buffered messages are flushed before the marker is
written
2. The marker itself is not disrupted by a concurrent rsyslog reload
3. rsyslog has time to naturally write the marker to disk

#### How did you verify/test it?
- Code review of the race condition timeline
- The fix eliminates the problematic pattern (write then immediate
reload) identified in the issue

---
> [!NOTE]
> This PR was generated with the assistance of an AI agent.

Signed-off-by: Ying Xie <[email protected]>
Signed-off-by: opcoder0 <[email protected]>