bug#23202: 24.5; emacsclient confusing server connection message

bug#23202: 24.5; emacsclient confusing server connection message

[Live System User]

When invoking `(server-start)' within ~/.emacs, Emacs corrrectly starts
up the server and creates the server file:

$ cat ~/.emacs.d/server/server | head -1
127.0.0.1:46791 18238

$ ps -ef | grep -v grep | grep 18238
liveuser 18238  7509  0 Mar31 pts/3    00:00:13 emacs

$  netstat -tulpa | grep 46791
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 localhost.localdo:46791 0.0.0.0:*               LISTEN      18238/emacs         



Now, when invoking emacsclient, I get the following message:

$ emacsclient +12:2 ~/.emacs
emacsclient: can't find socket; have you started the server?
To start the server in Emacs, type "M-x server-start".
Waiting for Emacs...


Even though I get this message, apparently. emacsclient does find the
network socket and brings up the "~/.emacs" file in an emacs window.

In Emacs, invoking `(list-processes)' yields:

server          listen  --              --           (network server on local)
server <127.... open    --              --           (network connection to 127.0.0.1)


.%  *Process List*          166 Process Menu     
  * .emacs                73761 Emacs-Lisp       ~/.emacs
 %  *GNU Emacs*             858 Fundamental      
    *scratch*               191 Lisp Interaction 
 %* *Messages*             2285 Messages         


So why give a warning message of "can't find socket" if the connection is
subsequentially successful (the server *was* started) and it gets its
connection information from the server file, even though the server file
is not an actual "socket"?

Could it be that invoking emacsclient, by default, first looks for the
server socket file in /tmp/emacs<UID>/server ?  And then falls back to
the ~/.emacs.d/server/server server file if that socket doesn't
exists?

But because of the default precedence. it doesn't determine whether a
server actually doesn't exists before emitting the warning?

Thanks.



In GNU Emacs 24.5.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.18.7)
 of 2016-02-03 on buildhw-05.phx2.fedoraproject.org
Windowing system distributor `Fedora Project', version 11.0.11799901
Configured using:
 `configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
 -m64 -mtune=generic' LDFLAGS=-Wl,-z,relro'

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Group

Minor modes in effect:
  gnus-undo-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Checking new news...done
Warning: Opening nnimap server on gmail...failed: ; Server nnimap+gmail previously determined to be down; not retrying; Opening nnimap server on gmail...failed: ; Server nnimap+gmail previously determined to be down; not retrying; Opening nnimap server on gmail...failed: ; Unable to open server nnimap+gmail due to: gmail/993 No address associated with hostname; Opening nnimap server on dada...failed: ; Opening nnimap server on gmail...failed: ; Unable to open server nnimap+gmail due to: gmail/993 No address associated with hostname
Auto-saving...
M-s e is undefined
Read ~/.gnus
v is undefined
e is undefined
Read ~/.gnus
Quit [2 times]
gnutls.c: [0] (Emacs) fatal error: Error in the pull function.

Load-path shadows:
~/.emacs.d/lisp/ntlm hides /usr/share/emacs/24.5/lisp/net/ntlm

Features:
(shadow sort mail-extr emacsbug sendmail mule-util server nndraft nnmh
nndoc utf-7 rfc2104 nnfolder nnimap utf7 parse-time netrc gnutls
network-stream starttls tls gnus-agent gnus-srvr gnus-score score-mode
nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime dig
mailcap nntp gnus-cache epa-file epa derived epg epg-config auth-source
eieio byte-opt bytecomp byte-compile cl-extra cconv eieio-core sieve
sieve-mode sieve-manage password-cache nnir gnus-sum gnus-group
gnus-undo nnmail mail-source gnus-start gnus-spec gnus-int gnus-range
message format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev
gmm-utils mailheader gnus-win gnus gnus-ems wid-edit cl-loaddefs cl-lib
nnoo nnheader gnus-util mm-util help-fns mail-prsvr mail-utils time-date
tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 215242 19509)
 (symbols 48 118916 0)
 (miscs 40 70 226)
 (strings 32 83510 6948)
 (string-bytes 1 3112521)
 (vectors 16 20051)
 (vector-slots 8 576302 11990)
 (floats 8 226 496)
 (intervals 56 544 18)
 (buffers 960 29)
 (heap 1024 60858 19399))

bug#23202: 24.5; emacsclient confusing server connection message

[Lars Ingebrigtsen]

Live System User <nyc4bos@aol.com> writes:

> Now, when invoking emacsclient, I get the following message:
>
> $ emacsclient +12:2 ~/.emacs
> emacsclient: can't find socket; have you started the server?
> To start the server in Emacs, type "M-x server-start".
> Waiting for Emacs...
>
>
> Even though I get this message, apparently. emacsclient does find the
> network socket and brings up the "~/.emacs" file in an emacs window.
>
> In Emacs, invoking `(list-processes)' yields:
>
> server          listen  --              --           (network server on local)
> server <127.... open    --              --           (network connection to 127.0.0.1)
>
>
> .%  *Process List*          166 Process Menu     
>   * .emacs                73761 Emacs-Lisp       ~/.emacs
>  %  *GNU Emacs*             858 Fundamental      
>     *scratch*               191 Lisp Interaction 
>  %* *Messages*             2285 Messages         
>
>
> So why give a warning message of "can't find socket" if the connection is
> subsequentially successful (the server *was* started) and it gets its
> connection information from the server file, even though the server file
> is not an actual "socket"?
>
> Could it be that invoking emacsclient, by default, first looks for the
> server socket file in /tmp/emacs<UID>/server ?  And then falls back to
> the ~/.emacs.d/server/server server file if that socket doesn't
> exists?
>
> But because of the default precedence. it doesn't determine whether a
> server actually doesn't exists before emitting the warning?

(I'm going through old Emacs bug reports that haven't received any
response.)

I'm unable to reproduce this in Emacs 27.  Are you still seeing this
behaviour?

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

bug#23202: 24.5; emacsclient confusing server connection message

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Live System User <nyc4bos@aol.com> writes:
>
>> Now, when invoking emacsclient, I get the following message:
>>
>> $ emacsclient +12:2 ~/.emacs
>> emacsclient: can't find socket; have you started the server?
>> To start the server in Emacs, type "M-x server-start".
>> Waiting for Emacs...
>>
>>
>> Even though I get this message, apparently. emacsclient does find the
>> network socket and brings up the "~/.emacs" file in an emacs window.
>>
>> In Emacs, invoking `(list-processes)' yields:
>>
>> server          listen  --              --           (network server on local)
>> server <127.... open    --              --           (network connection to 127.0.0.1)
>>
>>
>> .%  *Process List*          166 Process Menu     
>>   * .emacs                73761 Emacs-Lisp       ~/.emacs
>>  %  *GNU Emacs*             858 Fundamental      
>>     *scratch*               191 Lisp Interaction 
>>  %* *Messages*             2285 Messages         
>>
>>
>> So why give a warning message of "can't find socket" if the connection is
>> subsequentially successful (the server *was* started) and it gets its
>> connection information from the server file, even though the server file
>> is not an actual "socket"?
>>
>> Could it be that invoking emacsclient, by default, first looks for the
>> server socket file in /tmp/emacs<UID>/server ?  And then falls back to
>> the ~/.emacs.d/server/server server file if that socket doesn't
>> exists?
>>
>> But because of the default precedence. it doesn't determine whether a
>> server actually doesn't exists before emitting the warning?
>
> (I'm going through old Emacs bug reports that haven't received any
> response.)
>
> I'm unable to reproduce this in Emacs 27.  Are you still seeing this
> behaviour?

I'm also unable to reproduce this on Emacs 27.  Since more information
was requested, but none was given within 14 weeks, I'm now closing
this bug as unreproducible.

If anyone can reproduce this, please report back and/or reopen the bug
report.

Best regards,
Stefan Kangas