Jump to content

Variety8037

Members
  • Posts

    4
  • Joined

  • Last visited

About Variety8037

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    Cyprus
  1. The collect_logs.sh was creating a 32MB tar.gz, I had to find a better way. I cleaned /var/log and looked at what's happening shortly after starting efs.service. It does not take long for the first rtp timeout to show up. Please note that I have scrubbed user and host info ~/.EncryptedVault is the cipherdir for a gocryptfs user mounted encrypted directory of mine. The allow_other mount options is not present. So not even root can read the files under Vault. Could this be triggering the problem? I doubt it, because if I keep looking in the syslog, there are timeouts happening on paths that have nothing to do with Vault
  2. I have 4 physical cores (8 logical cores). The support ticket is raised as #00520204, so the ball is rolling on that side as well.
  3. It's PoP OS, which is an Ubuntu derivative. Weird, now I look for collect_logs.sh and it is present. Never mind. Is there a particular file from the collected logs tar.gz that I should post? I cannot post the entire tar gz here because it contains information that has not been anonymized (syslog for example). But I could imagine doing that in the support ticket if there is an upload capability there.
  4. What is to blame here? Is it a local issue or an issue with an ESET server under high load? Until I understand where the locus of this failure mode is, I cannot justify the time spent looking at this issue, and must stop efs.service. I saw a couple other topics on this, but never a clear statement or outcome, or a resulting KB to spread the knowledge about this error message which I'm sure a lot of people have experienced, and will continue to experience. Related ticket I filed today to get the ball rolling with support: #00520204
×
×
  • Create New...