From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id D7BC596B50 for ; Tue, 16 Apr 2024 14:13:55 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B1BDA1A179 for ; Tue, 16 Apr 2024 14:13:25 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Tue, 16 Apr 2024 14:13:25 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id EB8FE45023 for ; Tue, 16 Apr 2024 14:13:24 +0200 (CEST) Message-ID: Date: Tue, 16 Apr 2024 14:13:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Proxmox Backup Server development discussion , Gabriel Goller References: <20240412100631.94218-1-l.wagner@proxmox.com> <20240412100631.94218-15-l.wagner@proxmox.com> Content-Language: de-AT, en-US From: Lukas Wagner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.004 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH proxmox-backup 14/33] server: notifications: send GC notifications via notification system X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2024 12:13:55 -0000 On 2024-04-16 11:37, Gabriel Goller wrote: > On Fri Apr 12, 2024 at 12:06 PM CEST, Lukas Wagner wrote: >> diff --git a/src/server/gc_job.rs b/src/server/gc_job.rs >> index 41375d72..ff5bdccf 100644 >> --- a/src/server/gc_job.rs >> +++ b/src/server/gc_job.rs >> @@ -19,8 +19,6 @@ pub fn do_garbage_collection_job( >> ) -> Result { >> let store = datastore.name().to_string(); >> >> - let (email, notify) = crate::server::lookup_datastore_notify_settings(&store); >> - >> let worker_type = job.jobtype().to_string(); >> let upid_str = WorkerTask::new_thread( >> &worker_type, >> @@ -43,11 +41,9 @@ pub fn do_garbage_collection_job( >> eprintln!("could not finish job state for {}: {err}", job.jobtype()); >> } >> >> - if let Some(email) = email { >> - let gc_status = datastore.last_gc_status(); >> - if let Err(err) = send_gc_status(&email, notify, &store, &gc_status, &result) { >> - eprintln!("send gc notification failed: {err}"); >> - } >> + let gc_status = datastore.last_gc_status(); >> + if let Err(err) = send_gc_status(&store, &gc_status, &result) { >> + eprintln!("send gc notification failed: {err}"); > > I think we should use 'task_err!()' here. I know eprintln is used above, > and technically works because we redirect stderr in the service setup > but it's still slow and kinda the legacy method of printing task errors. I think the reason why the original code does not use task_log is because the job is already marked as finished at that point: if let Err(err) = job.finish(status) { eprintln!("could not finish job state for {}: {err}", job.jobtype()); } let gc_status = datastore.last_gc_status(); if let Err(err) = send_gc_status(&store, &gc_status, &result) { eprintln!("send gc notification failed: {err}"); } Other jobs seem to follow the same pattern - use task_log! before, and eprintln/log::error! after the job is finished. A `task_log!` after the job is finished still seems to work, but I'm not sure if that might lead to problems. What do you think? -- - Lukas