fix: Agent clippy and FAQ

Signed-off-by: Anthony Whalley <[email protected]>

Author: No9

FAQ.md

@@ -4,6 +4,8 @@
 
 - [Why is my core dump truncated?](#why-is-my-core-dump-truncated)
 
+- [Why is my zip file corrupted?](#why-is-my-zip-file-corrupted)
+
 - [Why is my log file exactly half of my configured line count?](#why-is-my-log-file-exactly-half-of-my-configured-line-count)
 
 - [Can I force an upload?](#can-i-force-an-upload)
@@ -12,6 +14,8 @@
 
 - [How do I use the custom endpoint?](#how-do-i-use-the-custom-endpoint)
 
+- [Why am I getting the wrong container info?](#why-am-i-getting-the-wrong-container-info)
+
 ## How should I integrate my own uploader?
 
 The core dump handler is designed to quickly move the cores *"off-box"* to an object storage environment with as much additional runtime information as possible.
@@ -73,6 +77,14 @@ terminationGracePeriodSeconds: 120
 ```
 Also see [Kubernetes best practices: terminating with grace](https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-terminating-with-grace)
 
+## Why is my zip file corrupted?
+
+As of v8.7.0 there is now have a timer on the core dump to prevent repeated hanging core dumps taking down the system.
+For very large core dumps this means the process can be truncated and the zipfile incomplete.
+
+In v8.8.0 We have added the nocompression option to zip process to improve performance and you can increase the timeout default which is currently set to 10 minutes.
+
+
 ## Why is my log file exactly half of my configured line count?
 
 This appears to be a bug in some kubernetes services.
@@ -134,3 +146,9 @@ extraEnvVars: |
     - name: S3_ENDPOINT
       value: https://the-endpoint
 ```
+
+## Why am I getting the wrong container info?
+
+Core dump handler trys to find the container information for the crashing process based on the hostname of the pod. This works fine in most scenarios but when pods are created directly in multiple namespaces or the same Statefulsets are created in the same namespaces.
+
+The current recommendation is to create a unique name in both of those scenarios. [See issue 115](https://github.com/IBM/core-dump-handler/issues/115)

core-dump-agent/src/main.rs

@@ -288,7 +288,7 @@ async fn main() -> Result<(), anyhow::Error> {
 async fn process_file(zip_path: &Path, bucket: &Bucket) {
     info!("Uploading: {}", zip_path.display());
 
-    let f = File::open(&zip_path).expect("no file found");
+    let f = File::open(zip_path).expect("no file found");
 
     match f.try_lock(FileLockMode::Shared) {
         Ok(_) => { /* If we can lock then we are ok */ }
@@ -305,7 +305,7 @@ async fn process_file(zip_path: &Path, bucket: &Bucket) {
         }
     }
 
-    let metadata = fs::metadata(&zip_path).expect("unable to read metadata");
+    let metadata = fs::metadata(zip_path).expect("unable to read metadata");
     info!("zip size is {}", metadata.len());
     let path_str = match zip_path.to_str() {
         Some(v) => v,
@@ -496,7 +496,7 @@ fn get_sysctl(name: &str) -> Result<String, anyhow::Error> {
     info!("Getting sysctl for {}", name);
     let output = Command::new("sysctl")
         .env("PATH", get_path())
-        .args(&["-n", name])
+        .args(["-n", name])
         .output()?;
     let lines = String::from_utf8(output.stdout)?;
     let line = lines.lines().take(1).next().unwrap_or("");
@@ -522,7 +522,7 @@ fn overwrite_sysctl(name: &str, value: &str) -> Result<(), anyhow::Error> {
     let s = format!("{}={}", name, value);
     let output = Command::new("sysctl")
         .env("PATH", get_path())
-        .args(&["-w", s.as_str()])
+        .args(["-w", s.as_str()])
         .status()?;
     if !output.success() {
         let e = Error::InvalidOverWrite {