From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 643A21FF389 for ; Wed, 8 May 2024 16:27:19 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 7B0A31935; Wed, 8 May 2024 16:27:22 +0200 (CEST) Message-ID: Date: Wed, 8 May 2024 16:26:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Proxmox VE development discussion , Dominik Csapak References: <20240508124112.2519552-1-d.csapak@proxmox.com> <20240508124112.2519552-2-d.csapak@proxmox.com> Content-Language: en-GB From: Thomas Lamprecht In-Reply-To: <20240508124112.2519552-2-d.csapak@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.053 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 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [main.rs, proxmox.com] Subject: Re: [pve-devel] [PATCH pve-esxi-import-tools 1/1] improve error handling before mounting X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On 08/05/2024 14:41, Dominik Csapak wrote: > when we fail early in the mount process, we did not log any error to the > syslog, but only the top most one to stderr. > > sadly we were not able to see them anywhere, so improve the log by > * log the complete error chain with log::error (so we also can see the > causes) > * add more context hints in main_do > > This can help debug issues where we failed early and could not see any > error output otherwise, e.g. this thread in the forum: > > https://forum.proxmox.com/threads/146248/ > > Signed-off-by: Dominik Csapak > --- > src/main.rs | 36 +++++++++++++++++++++++++++--------- > 1 file changed, 27 insertions(+), 9 deletions(-) > > diff --git a/src/main.rs b/src/main.rs > index 281ec3d..a8b2bb6 100644 > --- a/src/main.rs > +++ b/src/main.rs > @@ -1,4 +1,5 @@ > use std::ffi::{CString, OsStr, OsString}; > +use std::fmt::Write; > use std::io; > use std::os::fd::RawFd; > use std::os::unix::ffi::OsStrExt; > @@ -221,7 +222,12 @@ fn main() { > }); > > if let Err(err) = runtime.block_on(main_do()) { > - eprintln!("Error: {}", err); > + let mut err_chain = String::new(); > + for err in err.chain() { > + let _ = writeln!(err_chain, " {err}"); is the extra whitespace intended? At least the first line would then have two consecutive whitespaces, one from here and one from the prefix below on log and println. > + } > + println!("Error: {err}"); > + log::error!("Error: {err_chain}"); > std::process::exit(-1); > } > } > @@ -236,15 +242,15 @@ async fn main_do() -> Result<(), Error> { > usage(&arg0, std::io::stderr(), 1); > } > }; > - parse_manifest(&args.manifest)?; > + parse_manifest(&args.manifest).context("failed to parse manifest")?; > > let change_uid = match args.change_user.as_deref() { > - Some(user) => Some(get_uid(user)?), > + Some(user) => Some(get_uid(user).context("failed to get uid")?), > None => None, > }; > > let change_gid = match args.change_group.as_deref() { > - Some(group) => Some(get_gid(group)?), > + Some(group) => Some(get_gid(group).context("failed to get gid")?), > None => None, > }; > > @@ -255,10 +261,12 @@ async fn main_do() -> Result<(), Error> { > .enable_readdirplus(); > > for opt in args.mount_options { > - fuse = fuse.options_os(&opt)?; > + fuse = fuse > + .options_os(&opt) > + .context("failed to get fuse options")?; > } > > - unmount_if_mounted(&args.mount_path)?; > + unmount_if_mounted(&args.mount_path).context("failed to unmount")?; > > let mut fuse = fuse > .build() > @@ -302,9 +310,19 @@ async fn main_do() -> Result<(), Error> { > let fs_datastore = fs_datacenter.create_datastore(datastore); > > log::debug!("loading {datacenter:?}/{datastore:?}/{path:?}"); > - let config = > - vmx::VmConfig::parse(client.open_file(datacenter, datastore, path).await?, path) > - .await?; > + let config = vmx::VmConfig::parse( > + client > + .open_file(datacenter, datastore, path) > + .await > + .with_context(|| { > + format!("error opening file for: {datacenter} {datastore} {path}") should that context be added unconditionally in open_file? Also drop the `for: `, rather something like "error when opening file '{...}'" And FWIW, in above debug log the variable triple is printed as path, and it's also accessible that way on FS level, so might make sense to keep it that way. > + })?, can we move this to a separate `let config =` line before calling parse on is, this gets rather convoluted and with rust one can nicely override the same variable in an explicit way, so this here IMO better expressed that way. > + path, > + ) > + .await > + .with_context(|| { > + format!("failed to parse vm config for {datacenter} {datastore} {path}") > + })?; Similar here, isn't adding that context belonging in the parse fn itself? Might hold true for the static context too, as long as the context does not include call-site specific info, but only fn implementation-site one, they might be better added at the site of implementation to avoid potential repetition. also s/vm/VM/ > log::debug!("{config:#?}"); > for disk in config.disks.values() { > let other_fs_datastore; _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel