On 2020-12-27 at 11:14 +0000, Nikolaus Rath wrote: > On Dec 23 2020, "Jules F." <[email protected]> wrote: > > Actually it now happens when using the network cable to connect to > > the > > internet as well. I'm thinking it might be from one of the latest > > versions > > then. I still get no errors in mount.log between the mount time and > > crashing time. It works fine when backing up to a USB drive. > > This is *very* unlikely. Can you try running mount.s3ql in foreground > on > the console (--fg) and watch how it terminates? > > The only way for it to terminate without writing details into > mount.log > is for it to segfault (which should also be visible in your kernel > logs). And even in this case, you should see details in > ~/.s3ql/mount.s3ql_crit.log. > > (I am assuming you have ruled out permissions and disk full issues > for > the log directory). > > I would be very hesitant to use S3QL until you have figured this out > - > no matter which backend or network connection you use. Something is > fundamentally wrong with your installation. > > > Best, > -Nikolaus > > -- > GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F > > »Time flies like an arrow, fruit flies like a Banana.« >
Just a quick note, I've been experiencing an exactly identical problem since ~a month ago, B2 backend, no compression or encryption, stable Internet connection. Logs are inconclusive, no backtraces, nothing. The problem is reproducible 100% of the times. I'll send the full logs and other info shortly. -- Ivan Shapovalov / intelfx / -- You received this message because you are subscribed to the Google Groups "s3ql" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/s3ql/b385ca17e2a278ebe8a4fc6e461a578c61e4e2b7.camel%40intelfx.name.
signature.asc
Description: This is a digitally signed message part
