have emacs use SIGTERM to end a process instead of SIGHUP

have emacs use SIGTERM to end a process instead of SIGHUP

[John Leach]

Hi,

I'm starting a process using start-process-shell-command, but the
command I'm running doesn't exit when it receives a SIGHUP (it reloads
it's configs or something) so I end up with orphaned processes hanging
around when I close the buffer or exit emacs.

How can I have emacs send a SIGTERM instead of a SIGHUP to the processes
it manages?

fyi, I define a function to start the process like this:

> (defun nanoc-server ()
> 	"Runs a nanoc web server"
> 	(interactive)
> 	(let ((default-directory (repository-root)))
> 		(let ((process-connection-type t))
> 			(start-process-shell-command "nanoc-server" "nanoc-server" "bundle exec nanoc view -p 3005 -C")
> 			)))

Thanks in advance for any help,

John.
--
http://johnleach.co.uk

Re: have emacs use SIGTERM to end a process instead of SIGHUP

[Tassilo Horn]

John Leach <john@johnleach.co.uk> writes:

Hi John,

> I'm starting a process using start-process-shell-command, but the
> command I'm running doesn't exit when it receives a SIGHUP (it reloads
> it's configs or something) so I end up with orphaned processes hanging
> around when I close the buffer or exit emacs.

I guess you could add a function to `kill-buffer-hook' that calls
`delete-process' on the process.

Bye,
Tassilo

Re: have emacs use SIGTERM to end a process instead of SIGHUP

[Barry Margolin]

In article <mailman.586.1373322303.12400.help-gnu-emacs@gnu.org>,
 John Leach <john@johnleach.co.uk> wrote:

> Hi,
> 
> I'm starting a process using start-process-shell-command, but the
> command I'm running doesn't exit when it receives a SIGHUP (it reloads
> it's configs or something) so I end up with orphaned processes hanging
> around when I close the buffer or exit emacs.

That's really strange behavior for a non-daemon process. Wouldn't it 
have the same problem if you ran it from a normal terminal and 
disconnected?

SIGHUP is the expected signal when a process's terminal goes away.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: have emacs use SIGTERM to end a process instead of SIGHUP

[John Leach]

On 09/07/13 13:02, Tassilo Horn wrote:
> John Leach <john@johnleach.co.uk> writes:
> 
> Hi John,
> 
>> I'm starting a process using start-process-shell-command, but the
>> command I'm running doesn't exit when it receives a SIGHUP (it reloads
>> it's configs or something) so I end up with orphaned processes hanging
>> around when I close the buffer or exit emacs.
> 
> I guess you could add a function to `kill-buffer-hook' that calls
> `delete-process' on the process.

thanks Tassilo. I'm trying to do this but failing.

So I think I need a kill-buffer-hook that can get the process of the
current buffer, check if it looks like the process I know needs a
SIGTERM, and then send it one.

I'm wondering if I can set some kind of attribute on the buffer when I
create the process, so I can easily recognise it at kill time? Rather
than looking at the command line or something.

I'm lost with even the basic syntax to do any of this though. Could you
help?

Thanks,

John.

Re: have emacs use SIGTERM to end a process instead of SIGHUP

[John Leach]

On 09/07/13 16:19, Barry Margolin wrote:
> In article <mailman.586.1373322303.12400.help-gnu-emacs@gnu.org>,
>  John Leach <john@johnleach.co.uk> wrote:
> 
>> Hi,
>>
>> I'm starting a process using start-process-shell-command, but the
>> command I'm running doesn't exit when it receives a SIGHUP (it reloads
>> it's configs or something) so I end up with orphaned processes hanging
>> around when I close the buffer or exit emacs.
> 
> That's really strange behavior for a non-daemon process. Wouldn't it 
> have the same problem if you ran it from a normal terminal and 
> disconnected?
> 
> SIGHUP is the expected signal when a process's terminal goes away.
> 

true - it's probably a good idea for me to submit a patch to this
program to have it behave properly.

John.

Re: have emacs use SIGTERM to end a process instead of SIGHUP

[Tassilo Horn]

John Leach <john@johnleach.co.uk> writes:

>>> I'm starting a process using start-process-shell-command, but the
>>> command I'm running doesn't exit when it receives a SIGHUP (it
>>> reloads it's configs or something) so I end up with orphaned
>>> processes hanging around when I close the buffer or exit emacs.
>> 
>> I guess you could add a function to `kill-buffer-hook' that calls
>> `delete-process' on the process.
>
> thanks Tassilo. I'm trying to do this but failing.
>
> So I think I need a kill-buffer-hook that can get the process of the
> current buffer, check if it looks like the process I know needs a
> SIGTERM, and then send it one.
>
> I'm wondering if I can set some kind of attribute on the buffer when I
> create the process, so I can easily recognise it at kill time?

You could use a buffer-local variable.  E.g.

--8<---------------cut here---------------start------------->8---
(defvar nanoc-process nil)
(make-variable-buffer-local 'nanoc-process)

(defun nanoc-kill-process ()
  (when nanoc-process
    (delete-process nanoc-process)))

(defun nanoc-server ()
  "Runs a nanoc web server"
  (interactive)
  (let ((default-directory (repository-root))
        (process-connection-type t))
    (setq nanoc-process
          (start-process-shell-command
           "nanoc-server" "nanoc-server"
           "bundle exec nanoc view -p 3005 -C"))
    (add-hook 'kill-buffer-hook #'nanoc-kill-process nil t)))
--8<---------------cut here---------------end--------------->8---

Then every buffer may have its own nanoc-server process, and when
killing the buffer only that buffer's process is deleted.

Bye,
Tassilo

[OT, meta] markup (Re: have emacs use SIGTERM to end a process instead of SIGHUP)

[Emanuel Berg]

Tassilo Horn <tsdh@gnu.org> writes:

> --8<---------------cut here---------------start------------->8---
> (defvar nanoc-process nil)
> (make-variable-buffer-local 'nanoc-process)
>
> (defun nanoc-kill-process ()
>   (when nanoc-process
>     (delete-process nanoc-process)))
>
> (defun nanoc-server ()
>   "Runs a nanoc web server"
>   (interactive)
>   (let ((default-directory (repository-root))
>         (process-connection-type t))
>     (setq nanoc-process
>           (start-process-shell-command
>            "nanoc-server" "nanoc-server"
>            "bundle exec nanoc view -p 3005 -C"))
>     (add-hook 'kill-buffer-hook #'nanoc-kill-process nil t)))
> --8<---------------cut here---------------end--------------->8---

Are there any perks of this markup that I'm unaware of? I think it
just looks strange. I take it is configurable like everything
else, but it may be a wasted effort as my impression is that not
that many people use it. So it'd be interesting to hear.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: [OT, meta] markup (Re: have emacs use SIGTERM to end a process instead of SIGHUP)

[Tassilo Horn]

Emanuel Berg <embe8573@student.uu.se> writes:

>> --8<---------------cut here---------------start------------->8---
>> (defvar nanoc-process nil)
>> (make-variable-buffer-local 'nanoc-process)
>>
>> (defun nanoc-kill-process ()
>>   (when nanoc-process
>>     (delete-process nanoc-process)))
>>
>> (defun nanoc-server ()
>>   "Runs a nanoc web server"
>>   (interactive)
>>   (let ((default-directory (repository-root))
>>         (process-connection-type t))
>>     (setq nanoc-process
>>           (start-process-shell-command
>>            "nanoc-server" "nanoc-server"
>>            "bundle exec nanoc view -p 3005 -C"))
>>     (add-hook 'kill-buffer-hook #'nanoc-kill-process nil t)))
>> --8<---------------cut here---------------end--------------->8---
>
> Are there any perks of this markup that I'm unaware of?

Well, it's emphasized by Gnus (and maybe other emacs MUAs, too).

> I think it just looks strange.

Would you prefer org-mode blocks that are also font-locked with the
language-specific rules by Gnus (and probably other emacs MUAs)?

#+BEGIN_SRC emacs-lisp
(defvar nanoc-process nil)
(make-variable-buffer-local 'nanoc-process)

(defun nanoc-kill-process ()
  (when nanoc-process
    (delete-process nanoc-process)))

(defun nanoc-server ()
  "Runs a nanoc web server"
  (interactive)
  (let ((default-directory (repository-root))
        (process-connection-type t))
    (setq nanoc-process
          (start-process-shell-command
           "nanoc-server" "nanoc-server"
           "bundle exec nanoc view -p 3005 -C"))
    (add-hook 'kill-buffer-hook #'nanoc-kill-process nil t)))
#+END_SRC

IMHO, that's very nice when the reader uses Gnus, but if he doesn't, it
looks much more weird than the markers above.

> I take it is configurable like everything else, but it may be a wasted
> effort as my impression is that not that many people use it. So it'd
> be interesting to hear.

I use it cause it's convenient to use.

,----[ C-h k C-c M-m ]
| C-c M-m runs the command message-mark-inserted-region, which is an interactive
| compiled Lisp function in `message.el'.
| 
| It is bound to C-c M-m, <menu-bar> <Message> <Insert Region Marked>.
| 
| (message-mark-inserted-region BEG END &optional VERBATIM)
| 
| Mark some region in the current article with enclosing tags.
| See `message-mark-insert-begin' and `message-mark-insert-end'.
| If VERBATIM, use slrn style verbatim marks ("#v+" and "#v-").
`----

,----[ C-h k C-c M-f ]
| C-c M-f runs the command message-mark-insert-file, which is an interactive
| compiled Lisp function in `message.el'.
| 
| It is bound to C-c M-f, <menu-bar> <Message> <Insert File Marked...>.
| 
| (message-mark-insert-file FILE &optional VERBATIM)
| 
| Insert FILE at point, marking it with enclosing tags.
| See `message-mark-insert-begin' and `message-mark-insert-end'.
| If VERBATIM, use slrn style verbatim marks ("#v+" and "#v-").
| 
| [back]
`----

Bye,
Tassilo

Re: [OT, meta] markup (Re: have emacs use SIGTERM to end a process instead of SIGHUP)

[Emanuel Berg]

Tassilo Horn <tsdh@gnu.org> writes:

> --8<---------------cut here---------------start------------->8---
> ...
> it's emphasized by Gnus ...

I'm on Gnus, and what I see is: a goofy line "cut here ... start"
- and, the "highlight": a colored background. I don't think that
increases readability, to be honest (on the contrary). I thought
there might be something more - like - a predefined shortcut to
push it onto the kill ring, or something - but just for highlight,
my take is that it just looks goofy. (But I think I can change the
background color to black pretty easily, so by all means, stick to
it if you like it.)

> Would you prefer org-mode blocks that are also font-locked with
> the language-specific rules by Gnus (and probably other emacs
> MUAs)?

Yeah, that would be *great*! I've thought of that many times. But
- it doesn't work? What am I lacking?

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: [OT, meta] markup (Re: have emacs use SIGTERM to end a process instead of SIGHUP)

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> But I think I can change the background color to black

Yes: that face is `mm-uu-extract' and it is enough to set the
background to black (or whatever), as usual.

What face is that? "Face for extracted buffers." Gotcha :)

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: [OT, meta] markup (Re: have emacs use SIGTERM to end a process instead of SIGHUP)

[Tassilo Horn]

Emanuel Berg <embe8573@student.uu.se> writes:

Hi!

>> --8<---------------cut here---------------start------------->8---
>> ...
>> it's emphasized by Gnus ...
>
> I'm on Gnus, and what I see is: a goofy line "cut here ... start"
> - and, the "highlight": a colored background.

Normally, you wouldn't see the "cut here" lines, just the text with the
colored background, so you probably have configured there.

BTW, it also seems something else is broken with your Gnus.  Your
replies don't contain the message id of the article you're replying to
in the References header.  E.g., your message I'm just following up to
should contain <87sizfgd3l.fsf@thinkpad.tsdh.de> but doesn't.

>> Would you prefer org-mode blocks that are also font-locked with the
>> language-specific rules by Gnus (and probably other emacs MUAs)?
>
> Yeah, that would be *great*! I've thought of that many times. But - it
> doesn't work? What am I lacking?

What doesn't work?  Native font locking?  It might be you need to set
this:

  (setq org-src-fontify-natively t)

Bye,
Tassilo

Re: [OT, meta] markup (Re: have emacs use SIGTERM to end a process instead of SIGHUP)

[Emanuel Berg]

Tassilo Horn <tsdh@gnu.org> writes:

> Normally, you wouldn't see the "cut here" lines, just the text
> with the colored background, so you probably have configured
> there.

Not intentionally, because I've never seen that highlight method
until your message.

> BTW, it also seems something else is broken with your Gnus.
> Your replies don't contain the message id of the article you're
> replying to in the References header.  E.g., your message I'm
> just following up to should contain
> <87sizfgd3l.fsf@thinkpad.tsdh.de> but doesn't.

Interesting. Do you have any idea as to what that is, and what
implications it has?

> What doesn't work?  Native font locking?

I don't see any highlight or other face change, just text as
always. Tried to set the option, but I was too fast, so I forgot
to check what it was before I set it. Get back to you if it works
or not.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: [OT, meta] markup (Re: have emacs use SIGTERM to end a process instead of SIGHUP)

[Tassilo Horn]

Emanuel Berg <embe8573@student.uu.se> writes:

Hi Emanuel,

>> BTW, it also seems something else is broken with your Gnus.  Your
>> replies don't contain the message id of the article you're replying
>> to in the References header.  E.g., your message I'm just following
>> up to should contain <87sizfgd3l.fsf@thinkpad.tsdh.de> but doesn't.
>
> Interesting. Do you have any idea as to what that is, and what
> implications it has?

Newsreaders construct threads from the references, i.e., every article
mentions its ancestor articles.  Since the references in your articles
are wrong, every followup you make creates a new thread instead of being
displayed as a child of the article you are replying to.  It also breaks
Gnus' `^' and `A T' commands.

Bye,
Tassilo

Re: [OT, meta] markup (Re: have emacs use SIGTERM to end a process instead of SIGHUP)

[Emanuel Berg]

Tassilo Horn <tsdh@gnu.org> writes:

> Newsreaders construct threads from the references, i.e., every
> article mentions its ancestor articles.  Since the references in
> your articles are wrong, every followup you make creates a new
> thread instead of being displayed as a child of the article you
> are replying to.

Really? To be such a serious bug, it sure took a long while to get
to the surface!

And how can it be that *I* see the threads (including my posts)
correctly?

I didn't do that much Gnus configuration. What I did, I collected
at the URL, last.

But you already gave me some hints as to where I will start to
look.

http://user.it.uu.se/~embe8573/gnus/index.html

-- 
emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: [OT, meta] markup (Re: have emacs use SIGTERM to end a process instead of SIGHUP)

[Tassilo Horn]

Emanuel Berg <embe8573@student.uu.se> writes:

Hi!

>> Newsreaders construct threads from the references, i.e., every
>> article mentions its ancestor articles.  Since the references in
>> your articles are wrong, every followup you make creates a new
>> thread instead of being displayed as a child of the article you
>> are replying to.
>
> Really? To be such a serious bug, it sure took a long while to get to
> the surface!
>
> And how can it be that *I* see the threads (including my posts)
> correctly?

There are two ways to build threads: by reference and by same subjects.
Gathering by subjects is the default in Gnus nowadays.

,----[ C-h v gnus-summary-thread-gathering-function RET ]
| gnus-summary-thread-gathering-function is a variable defined in `gnus-sum.el'.
| Its value is gnus-gather-threads-by-references
| Original value was 
| gnus-gather-threads-by-subject
| 
|   This variable may be risky if used as a file-local variable.
| 
| Documentation:
| *Function used for gathering loose threads.
| There are two pre-defined functions: `gnus-gather-threads-by-subject',
| which only takes Subjects into consideration; and
| `gnus-gather-threads-by-references', which compared the References
| headers of the articles to find matches.
`----


> I didn't do that much Gnus configuration. What I did, I collected at
> the URL, last.
>
> But you already gave me some hints as to where I will start to look.
>
> http://user.it.uu.se/~embe8573/gnus/index.html

Hm, not sure what might be the culprit.  But what is `new-message' good
for, i.e., what does it do that C-x m (`compose-mail') with
`mail-user-agent' set to `gnus-user-agent' wouldn't also do?

Bye,
Tassilo

Re: [OT, meta] markup (Re: have emacs use SIGTERM to end a process instead of SIGHUP)

[Emanuel Berg]

Tassilo Horn <tsdh@gnu.org> writes:

> There are two ways to build threads: by reference and by same
> subjects.  Gathering by subjects is the default in Gnus
> nowadays.

So you get them the wrong way, because you sort by reference? And
I still get them correct. I see. *Still*, I like the reference
stuff to work.

> Hm, not sure what might be the culprit.  But what is
> `new-message' good for, i.e., what does it do that C-x m
> (`compose-mail') with `mail-user-agent' set to `gnus-user-agent'
> wouldn't also do?

I set that up to have a common interface for rmail and Gnus, for
sending messages. It might be better your way - I will try that,
now.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: [OT, meta] markup (Re: have emacs use SIGTERM to end a process instead of SIGHUP)

[Emanuel Berg]

Tassilo Horn <tsdh@gnu.org> writes:

> Hm, not sure what might be the culprit.  But what is
> `new-message' good for, i.e., what does it do that C-x m
> (`compose-mail') with `mail-user-agent' set to `gnus-user-agent'
> wouldn't also do?

OK, I looked into this.

`new-message' looks like the below code. I improved the docstring
a bit.

With `new-message', I can fill in the provided, blank headers like
this -

Newsgroups: alt.test
To: Emanuel Berg <embe8573@...>
Subject: test

- and then fire away: I'll get a mail, *and* alt.test will get a
post.

This is just an example (and I don't use it regularly), but I
think it is kind of cool.

Anyway, it seems to work *both* with `message-user-agent' and
`gnus-user-agent' as `mail-user-agent' (both mail and post work,
for both).

`compose-mail' with `gnus-user-agent' worked for mail, but not for
posts, when I gave it a "Newsgroup:" header manually.

Just to have done something, I changed to `gnus-user-agent' (for
the old new-message). But I don't see how that would help, because
Gnus has always been the sender in my interaction with Usenet.

(defun new-message ()
  "Open a new, empty message,
be it a Usenet post or a mail (or both),
with `gnus-post-news'.
This requires Gnus to run:
that is, there must be a *Group* buffer.
If there isn't, then `gnus' is started;
after that, a second attempt is made.
Also, a \"To:\" header is added, and point is moved
so that any typing will go into that header field."
  (interactive)
  (if (get-buffer "*Group*")
      (progn
        (gnus-post-news 'post "")
        (insert "\nTo: ")
        (transpose-lines 1)
        (set-buffer-modified-p nil)
        (goto-char 1)
        (end-of-line) )
    (progn
      (gnus)
      (new-message) )))

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: [OT, meta] markup (Re: have emacs use SIGTERM to end a process instead of SIGHUP)

[Emanuel Berg]

Tassilo Horn <tsdh@gnu.org> writes:

>>> Newsreaders construct threads from the references, i.e., every
>>> article mentions its ancestor articles.  Since the references in
>>> your articles are wrong, every followup you make creates a new
>>> thread instead of being displayed as a child of the article you
>>> are replying to.

And... *drumroll* now it works?

Re: [OT, meta] markup (Re: have emacs use SIGTERM to end a process instead of SIGHUP)

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> And... *drumroll* now it works?

In the post you posted, the one I replied to, it looked like this:

Message-ID: mailman.1423.1374252559.12400.help-gnu-emacs@gnu.org

In my reply, this seems to be correctly referenced last in the
header

References: ... mailman.1423.1374252559.12400.help-gnu-emacs@gnu.org

However, when you said that my Gnus was broke, it didn't look like
that to begin with, but like this:

87sizfgd3l.fsf@thinkpad.tsdh.de

I don't know, this may have something to do with the dual nature
(newsgroup/mailing list) of GEH.

I commented out these lines -

;; (insert "\nTo: ")
;; (transpose-lines 1)
;; (set-buffer-modified-p nil)
;; (goto-char 1)
;; (end-of-line) )

- from my `new-message' (pasted earlier). I don't know what, but
thing changed *something*, because now when I mail *and* send a
message to a newsgroup, the mail contains the following inserted
message:

The following message is a courtesy copy of an article
that has been posted to alt.test as well.

First, I thought Gnus added this when used to send mail, but I
tried it with both below configurations -

;; (setq mail-user-agent 'gnus-user-agent)
(setq mail-user-agent 'message-user-agent)

- and got the same message. And, this message did *not* appear
with the five commented lines above active.

Re: [OT, meta] markup (Re: have emacs use SIGTERM to end a process instead of SIGHUP)

[Tassilo Horn]

Emanuel Berg <embe8573@student.uu.se> writes:

Hi Emanuel,

>> And... *drumroll* now it works?
>
> In the post you posted, the one I replied to, it looked like this:
>
> Message-ID: mailman.1423.1374252559.12400.help-gnu-emacs@gnu.org
>
> In my reply, this seems to be correctly referenced last in the header
>
> References: ... mailman.1423.1374252559.12400.help-gnu-emacs@gnu.org

Hm, at least that last one seems correct.

> However, when you said that my Gnus was broke, it didn't look like
> that to begin with, but like this:
>
> 87sizfgd3l.fsf@thinkpad.tsdh.de

That's some message id of mine, which could be correct since you've
followed up to some message of me.  But I think it referred not to the
message you've replied to but to some older message.

> I don't know, this may have something to do with the dual nature
> (newsgroup/mailing list) of GEH.

I'm really not sure, but maybe the problem is that you sent every
message as email to the list and as posting to the newsgroup...

> - from my `new-message' (pasted earlier). I don't know what, but thing
> changed *something*, because now when I mail *and* send a message to a
> newsgroup, the mail contains the following inserted message:
>
> The following message is a courtesy copy of an article
> that has been posted to alt.test as well.
>
> First, I thought Gnus added this when used to send mail, but I
> tried it with both below configurations -
>
> ;; (setq mail-user-agent 'gnus-user-agent)
> (setq mail-user-agent 'message-user-agent)

That's inserted by message-mode which is also used by gnus.

> - and got the same message. And, this message did *not* appear
> with the five commented lines above active.

Bye,
Tassilo