DataSync: Added signal-triggered watched paths logging utility#30
DataSync: Added signal-triggered watched paths logging utility#30harsh-agarwal1 wants to merge 1 commit intoibm-openbmc:mainfrom
Conversation
7ef170b to
6988aae
Compare
289549b to
34a9729
Compare
README.md
Outdated
| If you want to check if some particular paths are being monitored or not, create | ||
| a file `/tmp/data_sync_check_watched_paths.txt` and enter the paths line by | ||
| line. Then send the signal, you can see the output in | ||
| `/tmp/data_sync_check_output.txt`. |
There was a problem hiding this comment.
Why is it txt file? Also capture sample output like how it would look like.
File name: data_sync_paths_info.json - lets maintain the same file name.
It could be JSON file, right? below one is not in specific format.
Individual user entered paths results:
Watching path: /var/lib
Not Watching path: ntest
How it would look like if I passed more than one path.
JSON
{
"Monitoring " : [path1, path2...],
"NotMonitoring" : [path3, path4...]
"UnsupportedPaths" : [path5, path6...] <-- User passed wrong paths
"MonitoringParentPaths" : <- The give path is not monitoring but monitoring its parent.
{
ConfiguredPaths : [path3, path4...],
MonitoringParentPath : [ParentPath3, ParentPath4]
}
}
is it make sense? I am not sure it much felisable to do but just thought to help our debuggability.
README.md
Outdated
|
|
||
| If the user input file is not present, then on receiving the signal, it will | ||
| write all the currently monitored path to | ||
| `/tmp/data_sync_current_watched_paths.json`. |
There was a problem hiding this comment.
data_sync_paths_info.json
Also capture sample output
JSON
{
"Monitoring " : [path1, path2...],
"MonitoringParentPaths" :
{
ConfiguredPaths : [path3, path4...],
MonitoringParentPath : [ParentPath3, ParentPath4]
}
}
|
|
||
| #include <filesystem> | ||
| #include <map> | ||
| #include <mutex> |
There was a problem hiding this comment.
To be honest, I’d prefer not to complicate the DataWatcher class. It should be driven by the Manager class, which can provide all the necessary debug details.
At the moment, I don’t have a concrete solution in mind—we’ll need to revisit this and find a cleaner approach. Any thoughts?
I was considering whether the Manager could maintain a container of DataWatcher objects, but that seems to violate the structured concurrency model of sender/receiver. So, I think we need to explore this further.
b1b9b20 to
7611cf4
Compare
- Introduced a mechanism to handle SIGUSR1 signal for debugging
purposes.
- Added support to read a list of paths from a user defined file
`/tmp/data_sync_paths_info.lsv` and log to same file whether each
path is currently being watched or not.
- To trigger send the SIGUSR1 signal to `phosphor-rbmc-data-sync-mgr`
- On receiving the SIGUSR1 signal, if user defined file is absent,
then the system logs all currently watched paths to
`/tmp/data_sync_paths_info.json`.
- Helps in live debugging and verification of inotify watch status
without restarting services.
Tested
- Added test cases.
- Verified on simics.
If `/tmp/data_sync_paths_info.lsv` present,
Example output file generated:
```bash
$ kill -10 1156
$ cat data_sync_paths_info.lsv
Individual user entered paths results:
Watching path: /var/lib
Not Watching path: ntest
```
If `/tmp/data_sync_paths_info.lsv` absent,
Example JSON file generated:
```bash
$ kill -10 1156
$ cat /tmp/data_sync_paths_info.json
[
"/var/lib",
"/var/lib/phosphor-state-manager"
]
```
Change-Id: I251fcf15c5307a2ceca5e464d0bd2ba1b98f7974
Signed-off-by: Harsh Agarwal <Harsh.Agarwal@ibm.com>
Tested
$ cat /tmp/current_watched_paths.json [ "/var/lib", "/var/lib/phosphor-state-manager" ]Change-Id: I251fcf15c5307a2ceca5e464d0bd2ba1b98f7974
Signed-off-by: Harsh Agarwal Harsh.Agarwal@ibm.com