unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Madhu <enometh@meer.net>
To: michael.albinus@gmx.de
Cc: emacs-devel@gnu.org
Subject: Re: {Spam?} Re: tramp "too many open files" [Re: bug#56606
Date: Sun, 26 Mar 2023 04:53:12 +0530 (IST)	[thread overview]
Message-ID: <20230326.045312.1258046693066266048.enometh@meer.net> (raw)
In-Reply-To: <87bkkmsb7b.fsf@gmx.de>

*  Michael Albinus <michael.albinus@gmx.de> <87bkkmsb7b.fsf@gmx.de>
Wrote on Tue, 21 Mar 2023 10:30:48 +0100
>>> Hmm. tramp-archive.el uses th GVFS file system to read a file
>>> archive. GVFS in this case uses libarchive(3).
>> I notice my gvfsd is not compiled with libarchive.
> No. gvfsd calls backends, /usr/libexec/gvfsd-archive in this case.

After I posted my message I had upgraded both libarchive and gvfsd
(1.45.3->1.50.4) and tried opening the zip attachment (which was now
saved via mew) with the / suffix and it worked as expected, without
blowing up, so nothing is actionable now.

My previous version of gvfsd did not have /usr/libexec/gvfsd-archive
when I reported the bug[1]

>> Usually I run without a system dbus (but with a session dbus for
>> emacs). tramp-archive disables itself when it finds it cannot connect
>> to a system dbus, so I was protected from it being triggered. (btw if
>> the situation changes, and a system dbus comes up later, it has to be
>> initialized explicitly with (dbus-init-bus :system))
> Right, although I'm not sure the system bus is needed. GVFS works over
> the session bus if I'm not mistaken. The system bus is needed for
> zeroconf only.

[tramp-gvfsd still seems to turn itself if it doesnt find the system
dbus enabled when it is first loaded. If the system bus comes up
later, emacs has to be made aware of it manually and tramp-gvfsd has
to be reloaded, and tramp-register-archive-autoload-file-name-handler
has to be invoked by hand before it can open archive files.]

---Best Regards, Madhu


>> I think I happened to have a system dbus when I triggered the
>> error. tramp found a gvfs and gvfs-fuse process, but it wouldn't have
>> worked because gvfds is not linked with libarchive.
> Again, the existence of gvfsd-archive is what counts. I believe

[1] A note to myself -- checked the ondisk zfs snapshot to make sure
it wasnt there when I triggered the blowup.  (Strangely I do seem to
have built a tarball of gvfs-1.46 in Nov 2020 to be installed and it
did have gvfsd-archive. If it had been installed I imagine a system
crash and zfs rollback had removed it)



  reply	other threads:[~2023-03-25 23:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <86ilnwafso.fsf@stephe-leake.org>
     [not found] ` <handler.56606.B.165800822832001.ack@debbugs.gnu.org>
     [not found]   ` <86a6989itv.fsf@stephe-leake.org>
     [not found]     ` <8335f0qbvn.fsf@gnu.org>
     [not found]       ` <831qujrjnm.fsf@gnu.org>
     [not found]         ` <86h73ex91m.fsf@stephe-leake.org>
     [not found]           ` <83k089omhb.fsf@gnu.org>
2023-03-20 13:31             ` tramp "too many open files" [Re: bug#56606 Madhu
2023-03-20 14:58               ` Thierry Volpiatto
2023-03-20 15:20                 ` Michael Albinus
2023-03-20 16:57                   ` Thierry Volpiatto
2023-03-20 17:56                     ` Michael Albinus
2023-03-21  5:55                       ` Thierry Volpiatto
2023-03-21  9:22                         ` Michael Albinus
2023-03-21 13:43                           ` Thierry Volpiatto
2023-03-21 15:17                             ` Michael Albinus
2023-03-21 17:19                               ` Thierry Volpiatto
2023-03-20 15:04               ` Michael Albinus
2023-03-20 18:47                 ` Madhu
2023-03-21  9:30                   ` Michael Albinus
2023-03-25 23:23                     ` Madhu [this message]
2023-03-26 18:56                       ` tramp "too many open files" Michael Albinus
2023-05-14  5:44                         ` Build failure: " Madhu
2023-05-14  7:10                           ` Michael Albinus
2023-05-14 10:00                             ` {Spam?} " Madhu
2023-05-14 11:24                               ` Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230326.045312.1258046693066266048.enometh@meer.net \
    --to=enometh@meer.net \
    --cc=emacs-devel@gnu.org \
    --cc=michael.albinus@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).