bug#44644: /tmp/emacs0/ not cleaned up upon exit

bug#44644: /tmp/emacs0/ not cleaned up upon exit

[積丹尼 Dan Jacobson]

Empty server-socket-dir /tmp/emacs0/ left on disk after exit when root.
# id
uid=0(root) gid=0(root) groups=0(root)
# emacs -Q -f server-start
^X^C
# ls -dl /tmp/emacs0/
drwx------ 2 root root 40 11-15 03:26 /tmp/emacs0/

See server.el: server-socket-dir is usually /run/user/nnn/emacs, except
when root, due to server-ensure-safe-dir .

Anyway leaving empty directories around after exit is bad when not root too.

emacs-version "27.1"

bug#44644: /tmp/emacs0/ not cleaned up upon exit

[Lars Ingebrigtsen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> Anyway leaving empty directories around after exit is bad when not root too.

True.  Looking at the code, it looks like having `server-start' add
`server-force-delete' to `kill-emacs-query-functions' would do the
trick?

Does anybody see any downsides to doing that?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44644: /tmp/emacs0/ not cleaned up upon exit

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 17 Nov 2020 00:06:43 +0100
> Cc: 44644@debbugs.gnu.org
> 
> 積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:
> 
> > Anyway leaving empty directories around after exit is bad when not root too.
> 
> True.  Looking at the code, it looks like having `server-start' add
> `server-force-delete' to `kill-emacs-query-functions' would do the
> trick?
> 
> Does anybody see any downsides to doing that?

What if the Emacs that's being killed is not the one that created the
server file?

bug#44644: /tmp/emacs0/ not cleaned up upon exit

[積丹尼 Dan Jacobson]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

EZ> What if the Emacs that's being killed is not the one that created the
EZ> server file?

Maybe double check via some kind of
$ lsof
call.

bug#44644: /tmp/emacs0/ not cleaned up upon exit

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> True.  Looking at the code, it looks like having `server-start' add
>> `server-force-delete' to `kill-emacs-query-functions' would do the
>> trick?
>> 
>> Does anybody see any downsides to doing that?
>
> What if the Emacs that's being killed is not the one that created the
> server file?

I didn't read the code closely enough -- emacs-server already does this,
but only deletes the /tmp/emacs0/server socket, but leaves the directory
behind.  As you say, there may be more than one server (with different
names), so deleting the directory may fail, but the final Emacs that
exits should successfully delete directory, at least, and I've added
that to Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44644: /tmp/emacs0/ not cleaned up upon exit

[Andreas Schwab]

On Nov 24 2020, Lars Ingebrigtsen wrote:

> I didn't read the code closely enough -- emacs-server already does this,
> but only deletes the /tmp/emacs0/server socket, but leaves the directory
> behind.  As you say, there may be more than one server (with different
> names), so deleting the directory may fail, but the final Emacs that
> exits should successfully delete directory, at least, and I've added
> that to Emacs 28.

This creates a race, which breaks the creation of the server file.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#44644: /tmp/emacs0/ not cleaned up upon exit

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> This creates a race, which breaks the creation of the server file.

It's a race, but the window is pretty narrow, isn't it?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44644: /tmp/emacs0/ not cleaned up upon exit

[Andreas Schwab]

On Nov 24 2020, Lars Ingebrigtsen wrote:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> This creates a race, which breaks the creation of the server file.
>
> It's a race, but the window is pretty narrow, isn't it?

A race is the worst kind of bugs.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#44644: /tmp/emacs0/ not cleaned up upon exit

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: jidanni@jidanni.org,  44644@debbugs.gnu.org
> Date: Tue, 24 Nov 2020 06:42:47 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> True.  Looking at the code, it looks like having `server-start' add
> >> `server-force-delete' to `kill-emacs-query-functions' would do the
> >> trick?
> >> 
> >> Does anybody see any downsides to doing that?
> >
> > What if the Emacs that's being killed is not the one that created the
> > server file?
> 
> I didn't read the code closely enough -- emacs-server already does this,
> but only deletes the /tmp/emacs0/server socket, but leaves the directory
> behind.  As you say, there may be more than one server (with different
> names), so deleting the directory may fail, but the final Emacs that
> exits should successfully delete directory, at least, and I've added
> that to Emacs 28.

Wait a moment: we are deleting the _directory_ of the server file?
Sorry, I was confused and thought you were talking about the server
file itself.

The directory thing is different.  First, its place and purpose
depends on whether server-use-tcp is nil (Posix platforms) or not
(MS-Windows or when the user of a Posix host connects from another
system).  If this is non-nil, the directory of the server file is
server-auth-dir, which is:

  (defcustom server-auth-dir (locate-user-emacs-file "server/")

Since this is a defcustom, I don't think we can delete that directory
behind user's back, even if it is empty.

If server-use-tcp is nil (the default), then the directory of
server-file is computed thusly:

  (defvar server-socket-dir
    (if internal--daemon-sockname
	(file-name-directory internal--daemon-sockname)
      (and (featurep 'make-network-process '(:family local))
	   (let ((xdg_runtime_dir (getenv "XDG_RUNTIME_DIR")))
	     (if xdg_runtime_dir
		 (format "%s/emacs" xdg_runtime_dir)
	       (format "%s/emacs%d" (or (getenv "TMPDIR") "/tmp") (user-uid))))))

I don't think it's kosher to delete $XDG_RUNTIME_DIR, even if it's
empty, since it is probably used by more than the server?  And if
XDG_RUNTIME_DIR is not defined, and we use a directory under /tmp,
then the system cleans that up from time to time, doesn't it?

So bottom line, I don't think we should do this, at least not
unconditionally.

bug#44644: /tmp/emacs0/ not cleaned up upon exit

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-11-24 18:29]:
> Wait a moment: we are deleting the _directory_ of the server file?
> Sorry, I was confused and thought you were talking about the server
> file itself.
> 
> The directory thing is different.  First, its place and purpose
> depends on whether server-use-tcp is nil (Posix platforms) or not
> (MS-Windows or when the user of a Posix host connects from another
> system).  If this is non-nil, the directory of the server file is
> server-auth-dir, which is:
> 
>   (defcustom server-auth-dir (locate-user-emacs-file "server/")
> 
> Since this is a defcustom, I don't think we can delete that directory
> behind user's back, even if it is empty.

Good point, as sometimes I was in that directory and launching from it
stuff related to Emacs leaving few notes, I would not like directory
being deleted for user, but customization could be given as optional.

> If server-use-tcp is nil (the default), then the directory of
> server-file is computed thusly:
> 
>   (defvar server-socket-dir
>     (if internal--daemon-sockname
> 	(file-name-directory internal--daemon-sockname)
>       (and (featurep 'make-network-process '(:family local))
> 	   (let ((xdg_runtime_dir (getenv "XDG_RUNTIME_DIR")))
> 	     (if xdg_runtime_dir
> 		 (format "%s/emacs" xdg_runtime_dir)
> 	       (format "%s/emacs%d" (or (getenv "TMPDIR") "/tmp") (user-uid))))))
> 
> I don't think it's kosher to delete $XDG_RUNTIME_DIR, even if it's
> empty, since it is probably used by more than the server?  And if
> XDG_RUNTIME_DIR is not defined, and we use a directory under /tmp,
> then the system cleans that up from time to time, doesn't it?

My XDG_RUNTIME_DIR is used as RAM disk to place thousands and
thousands of files temporarily there that I spare my hard disk of
those temporary file generations, and files are then uploaded to
servers as web pages. Images are being placed in that directory.

That directory removes all its data upon system reboot. No need to
delete directories definitely.

One could just delete the specific file file.pid or various sockets if
such do not exist any more and if such files have been created by
program. 

This is report that I use that directory since many years and before
XDG_RUNTIME_DIR I have used the memory directory how it was called I
forgot, maybe /dev/shm something, now is /run/user/1001 for each user
special.

bug#44644: /tmp/emacs0/ not cleaned up upon exit

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think it's kosher to delete $XDG_RUNTIME_DIR, even if it's
> empty, since it is probably used by more than the server?  And if
> XDG_RUNTIME_DIR is not defined, and we use a directory under /tmp,
> then the system cleans that up from time to time, doesn't it?
>
> So bottom line, I don't think we should do this, at least not
> unconditionally.

You raise some very good points.  Perhaps the only case where deleting
the directory is the one described in the subject?  I.e., when the
server directory has been created in `temporary-file-directory'?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44644: /tmp/emacs0/ not cleaned up upon exit

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: jidanni@jidanni.org,  44644@debbugs.gnu.org
> Date: Wed, 25 Nov 2020 07:13:36 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't think it's kosher to delete $XDG_RUNTIME_DIR, even if it's
> > empty, since it is probably used by more than the server?  And if
> > XDG_RUNTIME_DIR is not defined, and we use a directory under /tmp,
> > then the system cleans that up from time to time, doesn't it?
> >
> > So bottom line, I don't think we should do this, at least not
> > unconditionally.
> 
> You raise some very good points.  Perhaps the only case where deleting
> the directory is the one described in the subject?  I.e., when the
> server directory has been created in `temporary-file-directory'?

At most, yes.  The problem is, it isn't easy to know when the
directory is under /tmp (we don't use temporary-file-directory, for
the reasons explained in the comment to server-socket-dir).  Maybe we
should put some special property on server-dir when that is the case?

bug#44644: /tmp/emacs0/ not cleaned up upon exit

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> At most, yes.  The problem is, it isn't easy to know when the
> directory is under /tmp (we don't use temporary-file-directory, for
> the reasons explained in the comment to server-socket-dir).  Maybe we
> should put some special property on server-dir when that is the case?

Did you mean server-socket-dir instead of server-dir here?  Yes, I guess
that'd be possible, but the user may change server-socket-dir without
changing the property...

We could literally just check whether the parent of server-socket-dir is
"/tmp" and only delete then.  It'd be pretty defensive, but should fix
this minor annoyance.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44644: /tmp/emacs0/ not cleaned up upon exit

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: jidanni@jidanni.org,  44644@debbugs.gnu.org
> Date: Fri, 27 Nov 2020 08:48:30 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > At most, yes.  The problem is, it isn't easy to know when the
> > directory is under /tmp (we don't use temporary-file-directory, for
> > the reasons explained in the comment to server-socket-dir).  Maybe we
> > should put some special property on server-dir when that is the case?
> 
> Did you mean server-socket-dir instead of server-dir here?

Yes, sorry.

> Yes, I guess that'd be possible, but the user may change
> server-socket-dir without changing the property...
> 
> We could literally just check whether the parent of server-socket-dir is
> "/tmp" and only delete then.  It'd be pretty defensive, but should fix
> this minor annoyance.

If no better ideas come to mind, yes.

I actually don't share the feeling of an annoyance here: /tmp is
regularly cleaned up anyway, right?  But that's me.

bug#44644: /tmp/emacs0/ not cleaned up upon exit

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-11-27 11:13]:
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: jidanni@jidanni.org,  44644@debbugs.gnu.org
> > Date: Fri, 27 Nov 2020 08:48:30 +0100
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > At most, yes.  The problem is, it isn't easy to know when the
> > > directory is under /tmp (we don't use temporary-file-directory, for
> > > the reasons explained in the comment to server-socket-dir).  Maybe we
> > > should put some special property on server-dir when that is the case?
> > 
> > Did you mean server-socket-dir instead of server-dir here?
> 
> Yes, sorry.
> 
> > Yes, I guess that'd be possible, but the user may change
> > server-socket-dir without changing the property...
> > 
> > We could literally just check whether the parent of server-socket-dir is
> > "/tmp" and only delete then.  It'd be pretty defensive, but should fix
> > this minor annoyance.
> 
> If no better ideas come to mind, yes.
> 
> I actually don't share the feeling of an annoyance here: /tmp is
> regularly cleaned up anyway, right?  But that's me.

Many applications that use some directory in /tmp leave directories
there. It should be cleaned up by system on next run.

If users can customize directory place they could use all kinds of
parent directory names

And if directory should be deleted, then such should be checked not to
contain any other file that could be placed in directory.

Recently when running debugging various .heap and mtrace files are all
over the system. If directory is inspected by Emacs under debugging,
some files would be placed there automatically.

bug#44644: /tmp/emacs0/ not cleaned up upon exit

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> We could literally just check whether the parent of server-socket-dir is
>> "/tmp" and only delete then.  It'd be pretty defensive, but should fix
>> this minor annoyance.
>
> If no better ideas come to mind, yes.

OK, done.

> I actually don't share the feeling of an annoyance here: /tmp is
> regularly cleaned up anyway, right?  But that's me.

Only on reboot, and some people have machines running for months, so
keeping /tmp clean-ish is something programs usually try to do.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44644: /tmp/emacs0/ not cleaned up upon exit

[積丹尼 Dan Jacobson]

>>>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:
LI> Eli Zaretskii <eliz@gnu.org> writes:

>> I actually don't share the feeling of an annoyance here: /tmp is
>> regularly cleaned up anyway, right?  But that's me.

LI> Only on reboot, and some people have machines running for months, so
LI> keeping /tmp clean-ish is something programs usually try to do.

Indeed. What if every program had the attitude "Gee, I don't know how to
deal with my garbage. Maybe I'll just leave it sitting here and the
Environmental Protection Bureau will do something with it."

Because 99% of programs are environmentally responsible, that why /tmp
is still usable!

Else it would quickly cause even your SSD to stop spinning.