Re: GNU Emacs now runs in foreground

[Jonathan de Boyne Pollard]

Jonathan de Boyne Pollard:
One of the interesting developments over the past couple of decades is 
how much the world has been influenced to come around to the 
daemontools way of doing this. I've observed before, elsewhere, the 
number of daemon programs, especially in the BSD worlds, that have in 
that time gained -F/--foreground or similar options that tell them not 
to do a whole bunch of this unnecessary stuff.


Martin "eto" Misuth:
I think this is bit related to daemon(8) program which acts as poor 
man's runsv, with all the "advandages" of pid files.


It isn't, though.  Several of the manual pages that I've seen explicitly 
mention daemontools.  Here's winbindd's manual page, for example:



-F

If specified, this parameter causes the main winbindd process to not 
daemonize, i.e. double-fork and disassociate with the terminal. Child 
processes are still created as normal to service each connection 
request, but the main process does not exit. This operation mode is 
suitable for running winbindd under process supervisors such as 
supervise and svscan from Daniel J. Bernstein's daemontools package, 
or the AIX process monitor.

Re: GNU Emacs now runs in foreground

[Martin "eto" Misuth]

> On Thu, 8 Dec 2016 08:33:22 +
> Jonathan de Boyne Pollard  wrote:
>
> Martin "eto" Misuth:
> > On my presonal box "user level" s6 /services subtrees are in 
> > `.config/s6/host`   
> 
> For comparison: ~/.config/service-bundles/services/ and 
> ~/.config/service-bundles/targets/

Well what I like most is that I am in control, and I decide trees locations,
yet I can easily "merge trees" with system level supervisors.

Not just that, I can assemble "application subtrees" as well, that themselves
are "supervisable". 

Most importantly when paired with some scripting language, I can actually make
things that run on both systemdized linux machines, non systemdized linux
ones and on several other OSes.

> On Thu, 8 Dec 2016 08:33:22 +
> Jonathan de Boyne Pollard  wrote:
> 
> Martin "eto" Misuth:
> > #!/bin/sh
> > exec mpd --no-daemon /usr/home/eto/.config/mpd/mpd.conf  
> 
> Tip: In the daemontools world all services have ther own service 
> directory, at minimum; and this directory is the working directory of 
> the service.  You can put an mpd.conf that is particular to the service 
> in the service directory itself.
>
> On Thu, 08 Dec 2016 09:55:11 +
> "Laurent Bercot"  wrote:
>   Additionally, most Unix distributions traditionally keep their config
> files in /etc, and the change to a supervision system is already a big
> shock to them - the shock can be made easier to overcome if we don't
> change all the habits at once. :)
> 
>   Anyway, I don't think we should be arguing one way or the other;
> policy decisions are best left to sysadmins and distributions.

I use  with my own scripts, but for things having
local /etc, /usr/local/etc alternatives I prefer those.

> 
> Martin "eto" Misuth:
> > Getting tmux "supervised" was bit tricky as it double forks the daemon 
> > if not running, and is thus is "escaping under init" under normal 
> > conditions.  
> 
> Note: This can be easily handled on FreeBSD and TrueOS.  See NOTE_TRACK 
> in EVFILT_PROC for kevent().

I saw that filter, and tried to find examples, but my google-fu is not that good
these days of dumbed down search engines. The sad thing is that it is kqueue
only. Although kqueue is wonderful, it's BSDs only :). And although I would love
to have only BSDs on servers, I still have to have "exit path" into linux world.

But still kqueue is very nice indeed.

With other person on irc, we noticed there are some gotchas to subreaping,
especially reparented zombies don't sometimes (never?) generate SIGCHLD. 
I think that might be the reason why my PID1 s6-svscan on FreeBSD is
accumulating zombies sometimes (seems like it is affected by dead descendants of
ssh and my experiments).

More over although procctl() on BSDs allows one to enumerate whole subreaper
tree and even send signals atomically, it's not that ideal.

"No children" case detection with "nonblocking wait'n'see ECHILD" seems pretty
sufficient to me, at least for that for that one case. But i belive smething
better could be done.

Anyway as you are probably much closer to FreeBSD team than I am, what do 
you think are chances of subreaping capable BSDs to gain new kqueue note
NOTE_REPARENTED in EVFILT_PROC filter? 

This would allow one to simply "sleep" indefinitely in core of event loop until
reparented process is acquired as child, and add it to "wait_for" list for 
example.

Currently, I am noticing, that if I want to be 100% sure, that I "eat" also
reparented zombies, I need to wake up periodically.

> Martin "eto" Misuth:
> > It would be great if tmux project allowed to spawn raw user level 
> > daemon by explicit command,  
> 
> One of the interesting developments over the past couple of decades is 
> how much the world has been influenced to come around to the daemontools 
> way of doing this.  I've observed before, elsewhere, the number of 
> daemon programs, especially in the BSD worlds, that have in that time 
> gained -F/--foreground or similar options that tell them not to do a 
> whole bunch of this unnecessary stuff.

I think this is bit related to daemon(8) program which acts as poor man's runsv,
with all the "advandages" of pid files.
 
> It's in a way somewhat saddening to see the new option to emacs that 
> started this thread.  It's welcome; but the sad part is that it's a 
> decade and a half behind quite a lot of others.  For some systems like 
> emacs the process has been glacially slow.  MySQL is another. 
> daemontools users were asking about letting daemontools do the service 
> management and doing away with mysqld_safe in 2002.  It took thirteen 
> years for it to happen ... in MariaDB.  Oracle, where software goes to 
> die, may or may not have done the same for MySQL. PostgreSQL lags 
> further behind.

I am not so sure about PostgreSQL my experience differs a bit:

 "By default postgres starts in the foreground and prints log messages to 

Re: GNU Emacs now runs in foreground

[Jonathan de Boyne Pollard]

Martin "eto" Misuth:
On my presonal box "user level" s6 /services subtrees are in 
`.config/s6/host` 


For comparison: ~/.config/service-bundles/services/ and 
~/.config/service-bundles/targets/


Martin "eto" Misuth:

#!/bin/sh
exec mpd --no-daemon /usr/home/eto/.config/mpd/mpd.conf


Tip: In the daemontools world all services have ther own service 
directory, at minimum; and this directory is the working directory of 
the service.  You can put an mpd.conf that is particular to the service 
in the service directory itself.


Martin "eto" Misuth:
Getting tmux "supervised" was bit tricky as it double forks the daemon 
if not running, and is thus is "escaping under init" under normal 
conditions.


Note: This can be easily handled on FreeBSD and TrueOS.  See NOTE_TRACK 
in EVFILT_PROC for kevent().


Martin "eto" Misuth:
It would be great if tmux project allowed to spawn raw user level 
daemon by explicit command,


One of the interesting developments over the past couple of decades is 
how much the world has been influenced to come around to the daemontools 
way of doing this.  I've observed before, elsewhere, the number of 
daemon programs, especially in the BSD worlds, that have in that time 
gained -F/--foreground or similar options that tell them not to do a 
whole bunch of this unnecessary stuff.


It's in a way somewhat saddening to see the new option to emacs that 
started this thread.  It's welcome; but the sad part is that it's a 
decade and a half behind quite a lot of others.  For some systems like 
emacs the process has been glacially slow.  MySQL is another. 
daemontools users were asking about letting daemontools do the service 
management and doing away with mysqld_safe in 2002.  It took thirteen 
years for it to happen ... in MariaDB.  Oracle, where software goes to 
die, may or may not have done the same for MySQL. PostgreSQL lags 
further behind.


* http://jdebp.eu./Softwares/nosh/mariadb-and-mysql.html#Prompt

Re: GNU Emacs now runs in foreground

[Martin "eto" Misuth]

> On Tue, 6 Dec 2016 10:26:37 -0500
> Steve Litt  wrote:
>
> Thanks Martin,
> 
> Could you please show me your run scripts for tmux, screen and mpd?
> These are the three I could see myself using in this manner.
>  
> SteveT
> 
> Steve Litt 
> November 2016 featured book: Quit Joblessness: Start Your Own Business
> http://www.troubleshooters.com/startbiz
> 

Well, ... hmm, ... okay, ... but I am one of those people doing everything my
way despite what others tell me. I am sometimes embarassed about it as well
(still), but am slowly learning to not give a damn. 

I wanted to avoid complete disclosure, as I think one of my things is not
ready yet, but here is my infodumpy giant wall of text. I hope, I won't regret
it.

Currently I "share" my home dir with zfs send, between Void Linux notebook and
FreeBSD workstation. To ease my exploratory behaviour, for now, I am using dash
(on Void) and /bin/sh which are compatible for these kinds of things
(./run, ./finish). Workstation part is not used often, so not everything works
there yet.

I also have few FreeBSD servers with s6 only supervisions. Sometimes I use
execline but not always ... yet.

On my presonal box "user level" s6 /services subtrees are in `.config/s6/host`
for "host" level user services, (outside of xorg "sessions") and in
`.config/s6/xsession-0` is where default xorg session lives.

> - mpd - the music player daemon  

I am bit weird, so I run mpd as my own user as my music library is in my
/home. As I am sole user of the machine, I like it better that way. 
Mpd requires user to be in auxiliary audio group for ALSA access. 
I spawn whole s6 "host" tree with that group, with s6-applyuidgid, as I was
hinted by supervision folks on irc. I am still working on it though.
Runscript:
+--
|% cat .config/s6/host/mpd/run 
+--
|#!/bin/sh
|exec mpd --no-daemon /usr/home/eto/.config/mpd/mpd.conf
+--

MPD is configured to bind to explicit socket
+--
|% cat .config/mpd/mpd.conf | grep bind
+--
|bind_to_address"~/.config/mpd/run/socket"
+--

To be 100% sure ncmpcpp or X clients can find the socket I export it to X
session:
+--
|% cat .config/s6/xsession-0/.s6-svscan/env/MPD_HOST 
+--
|/usr/home/eto/.config/mpd/run/socket
+--

To be sure I can control(!) music with ncmpcpp on raw VT terminal, I modified
Void's agetty runit script to load given variable (maybe not the brightest
decision):
+--
|% cat /etc/runit/runsvdir/default/mybox-agetty-tty2/env/MPD_HOST
+--
|/usr/home/eto/.config/mpd/run/socket
+--

agetty also needed addition of `-o "-p -- \u"` switch to preserve environment.
One also might use pam_env, but I dislike pam.

Final result: uninterrupted music until I shut down computer or mpd service
itself, no matter whether X runs or not, or crashes (happens only when I am
messing with it), thus yy!

> On Tue, 6 Dec 2016 23:31:40 +
> Jonathan de Boyne Pollard  wrote:
>
> Martin "eto" Misuth:
> > - rxvt-unicode - uberterminal
> >  - this thing can operate [...] daemon, when single process hosts all
> > your terminals
> >  - benefits are [...]  
> 
> Drawbacks are that it doesn't understand receiving the listening socket 
> as an already-open file descriptor, and by default it places the socket 
> in $HOME/.urxvt/ rather than in /run/user/$USER/urxvt/ .

I personally am not so "hot" about this listening socket passing stuffs.
Don't get me wrong, I am learning to do it myself in my crappy attempts,
from scripting language, but I see it as important only in thightly coupled
swarms of cooperating processes.

I also see value in "piercing" something like FreeBSD jail and passing 
socket inside it - someting I would like to be able to do with vanilla nginx at
some point. Inside jail unix sockets are just fine to fan out data flows into
fastcgi handlers, database servers and whatnot. It is intereseting bcause that
way jail doesn't even need IP. Anybody wreaking havoc in it cannot reach
network...

However for normal "enduser" - ability to control and pass connection endpoints
between various process environments - is sufficient and much better design.
That way one can control access with unix permissons and whatnot. No need to
pack info about FD into env var and pass it in process state.

Thus env var for rxvt clients:
+--
|% cat .config/s6/xsession-0/.s6-svscan/env/RXVT_SOCKET
+--
|/usr/home/eto/.config/urxvt/run/socket
+--

And env var for rxvt server:
+--
|% cat .config/s6/host/urxvtd/env/RXVT_SOCKET
+--
|/usr/home/eto/.config/urxvt/run/socket
+--

As you see, terminal daemon currently runs "outside" of x session. 

It was experiment to see whether it kills all spawned "shell trees" when x goes
away. Which it of course does. Maybe Mr Schmorp would be willing to implement
feature to freeze shell instances in such cases? Who knows.

Now we get to most embarassing part:
  - after reading some info about proper "zombie reaping" on various djb
inspired sites 
- 

Re: GNU Emacs now runs in foreground

[Jonathan de Boyne Pollard]

Daniel Kahn Gillmor:

dbus-user-session supports at most one graphical session concurrently


... in order to avoid people encountering the very problem of 
half-hearted and flawed implementations that I described. 
Non-half-hearted implementations are the goal, however.


Read https://lists.debian.org/debian-devel/2016/08/msg00554.html and 
http://www.mail-archive.com/supervision@list.skarnet.org/msg01393.html .

GNU Emacs now runs in foreground

[Jonathan de Boyne Pollard]

Martin "eto" Misuth:

- rxvt-unicode - uberterminal
 - this thing can operate [...] daemon, when single process hosts all your 
terminals
 - benefits are [...]


Drawbacks are that it doesn't understand receiving the listening socket 
as an already-open file descriptor, and by default it places the socket 
in $HOME/.urxvt/ rather than in /run/user/$USER/urxvt/ .


Martin "eto" Misuth:

   - mpd - the music player daemon


This can accept listening sockets passed to it.  I've added to the nosh 
bundles package a service bundle for it as a system-wide instance, and 
generators in the configuration import subsystem for per-user 
instances.  You'll see these in version 1.30.

Re: GNU Emacs now runs in foreground

[Steve Litt]

On Tue, 6 Dec 2016 12:15:49 +
Jonathan de Boyne Pollard 
wrote:

> Martin "eto" Misuth:
> > First, there are two major caveats,  
> 
> There are actually three.  They break scripting.  For example: People 
> cannot use the GNOME Editor as $VISUAL or $EDITOR because one of the 
> things implicit in the $EDITOR/$VISUAL mechanism is that when the 
> program that has been invoked exits, the editing is over and the file 
> being edited has been saved in the desired form.  That is not the 
> behaviour of the "small and lightweight" GNOME Editor, however.

I think I can live without GNOME, so for me this is no problem at all. I
think a lot of people on this list can live without GNOME.

> 
> * http://unix.stackexchange.com/questions/201900/
> 
> * http://unix.stackexchange.com/a/323700/5132
> 
> * https://news.ycombinator.com/item?id=13056252
> 
> Other "interesting" problems result from the move that the Desktop
> Bus and the Desktop Environment people are making away from
> per-session instances of the D-BUS daemon to per-user instances of
> the same.  This causes fun with deciding what the daemon's $DISPLAY
> should be set to.  A per-session Desktop Bus obviously has one
> $DISPLAY by and large.  But a per-user Desktop Bus not only has to
> handle multiple logins from a single user, it has to handle that the
> per-user session management can be running when there's no X server
> at all.  

Dbus isn't part of my world, and when software tries to make dbus part
of my world, I tend to ditch that software. Dbus is a traffic circle
allowing everything to talk to everything else, addressing allowing.
It's a system-wide global variable on steroids.

> (systemd starts its per-user instances via PAM hooks that
> act upon every login, including logins over SSH and on terminals.)

If dbus isn't part of my world, then it's safe to say systemd isn't
part of my universe. If systemd were relevant to my life, I'd still be
on the Debian-User mailing list, not on this list. I don't
think I'm alone on this.


> Even though some daemons try to take the approach that the daemon
> supports multiple $DISPLAYs, sent in from multiple clients as part of
> the client session, one unfortunately finds that the daemons
> themselves still have to have an arbitrary $DISPLAY in order to start
> up in their initial, not connected to any clients and their displays
> yet, mode.  In practice, thus, the implementation of the user-wide
> client-server idea is half-hearted and flawed in this respect.

Well, maybe. But I'm going to try it.

To me, Linux is and should remain a DIY accessible OS, and that
requires shunning all things FreeDesktop.Org.

SteveT

Steve Litt 
November 2016 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz

Re: GNU Emacs now runs in foreground

[Steve Litt]

On Tue, 6 Dec 2016 10:40:20 +0100
"Martin \"eto\" Misuth"  wrote:


> I am immense fan of these user-level daemons (maybe they should have
> some more exact name).
> 
> First, there are two major caveats, that I noticed, being seen as
> disadvantages, to this design:
>  
>   1 - When such daemon crashes, your whole session is taken out. For
> example all terminals die, all shell process trees go out (make), so
> you can loose quite a lot of work.
> 
>   2 - There is more moving parts in these setups, and when you are
>   unawarare of supervision, it might be hard to manage these daemons
>   efficiently.
> 
> Software designed for this mode of operation obviously includes emacs
> now. Teams and authors behind these, usually have pretty good
> abilities and experience, as obviously designing this way requires
> some kind of architecture. Thus most of these packages dont suck, and
> are quite reliable.
> 
> I personaly use/know these:
> 
>   - super famous tmux - terminal multiplexer
> - you are probably aware of that one, handles lots of terminal
> sessions
> 
>   - gnu screen - terminal multiplexer
> - older and poorer cousin of tmux
> 
>   - mpd - the music player daemon - basically music player 
> - when spawned as it's own service outside of/before X it can
> keep music playing even as you are tweaking you xorg.conf :)
> - can route music over fifos through network and make many
> amchines play same music

Thanks Martin,

Could you please show me your run scripts for tmux, screen and mpd?
These are the three I could see myself using in this manner.
 
SteveT

Steve Litt 
November 2016 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz

GNU Emacs now runs in foreground

[Jonathan de Boyne Pollard]

Martin "eto" Misuth:

First, there are two major caveats,


There are actually three.  They break scripting.  For example: People 
cannot use the GNOME Editor as $VISUAL or $EDITOR because one of the 
things implicit in the $EDITOR/$VISUAL mechanism is that when the 
program that has been invoked exits, the editing is over and the file 
being edited has been saved in the desired form.  That is not the 
behaviour of the "small and lightweight" GNOME Editor, however.


* http://unix.stackexchange.com/questions/201900/

* http://unix.stackexchange.com/a/323700/5132

* https://news.ycombinator.com/item?id=13056252

Other "interesting" problems result from the move that the Desktop Bus 
and the Desktop Environment people are making away from per-session 
instances of the D-BUS daemon to per-user instances of the same.  This 
causes fun with deciding what the daemon's $DISPLAY should be set to.  A 
per-session Desktop Bus obviously has one $DISPLAY by and large.  But a 
per-user Desktop Bus not only has to handle multiple logins from a 
single user, it has to handle that the per-user session management can 
be running when there's no X server at all.  (systemd starts its 
per-user instances via PAM hooks that act upon every login, including 
logins over SSH and on terminals.) Even though some daemons try to take 
the approach that the daemon supports multiple $DISPLAYs, sent in from 
multiple clients as part of the client session, one unfortunately finds 
that the daemons themselves still have to have an arbitrary $DISPLAY in 
order to start up in their initial, not connected to any clients and 
their displays yet, mode.  In practice, thus, the implementation of the 
user-wide client-server idea is half-hearted and flawed in this respect.

Re: GNU Emacs now runs in foreground

[Jean Louis]

On Tue, Dec 06, 2016 at 10:40:20AM +0100, Martin "eto" Misuth wrote:
>   - mpd - the music player daemon - basically music player 
> - when spawned as it's own service outside of/before X it can keep music
>   playing even as you are tweaking you xorg.conf :)
> - can route music over fifos through network and make many amchines play
>   same music

I will try that one, when I figure out how to configure it.

>   - rxvt-unicode - uberterminal 
> - this thing can operate as normal xterm-like term (process per session),
>   or as daemon, when single process hosts all your terminals
> - benefits are increased new terminal startup speed (on my current box,
>   this is subsecond delay - helps when you treat terms as disposable
>   "surfaces"), and supposedly memory conservation, as lots of data is 
> shared
>   between the windows

I was always using rxvt, and now not any more. Just xterm. It is bound
to keys alt-ctrl-t and it quickly jumps up in front of me (maybe
because other terms are already running). And I like the loggin
feature, SVG screen dump and HTML dump. It is bloated, but working well.

>   - quassel - irc client
> - irc client core runs as headless daemon, client present interface
> - requires Qt and is quite heavy

If I use GNU Emacs, the erc IRC client is there, so no need for me.

> Many other things can be "adapted" to daemon, for example aria2c downloader
> supports xmlrpc interface. There is slew of bittorrent clients, that can be 
> run
> this way.

In user-space, I am using HTTP server, fetching emails from servers,
backup, and cron (using mcron in Guile).

> Regarding "major" problem 1., that of crashing, rxvt-unicode is most "felt" 
> when
> it trips over. Fortunately it is incredibly stable - I have crash it maybe one
> or two times in 7 years time frame, daily use. I usually have 10-100 open
> terminals per xsession.

Wow so many?

I have put in .bashrc:

# Logging of .bashrc opening
# file: terminalsopened.log is: chattr +a 
echo Terminal: `/bin/date +'%F-%T'` >> 
/home/data1/protected/tmp/terminalsopened.log 2> /dev/null

So that I get a lot of how many times I open a terminal. Since
2016-01-03, until today, 18,979 times, or some 1700+ times per month,
or 56 - 60 times per day.

Jean Louis

Re: GNU Emacs now runs in foreground

[Martin "eto" Misuth]

> On Thu, 1 Dec 2016 12:54:38 -0500
> Steve Litt  wrote:
>
> > On Thu, 1 Dec 2016 20:48:37 +0300
> > Jean Louis  wrote:
> > I have a strange feeling that you are joking...  
> 
> Not at all. You know mplayer can interact via a FIFO.
> 
> Seriously, I'm not joking. I'm always interested in new ways to use my
> computer.
> 
> SteveT

So you claim you are not joking, heh. I hope that is not coming from sarcasm
mode still. Ok, there exists some of this stuff, but is not that common.

I am immense fan of these user-level daemons (maybe they should have some more
exact name).

First, there are two major caveats, that I noticed, being seen as
disadvantages, to this design:
 
  1 - When such daemon crashes, your whole session is taken out. For example
  all terminals die, all shell process trees go out (make), so you can loose
  quite a lot of work.

  2 - There is more moving parts in these setups, and when you are
  unawarare of supervision, it might be hard to manage these daemons
  efficiently.

Software designed for this mode of operation obviously includes emacs now.
Teams and authors behind these, usually have pretty good abilities and
experience, as obviously designing this way requires some kind of architecture.
Thus most of these packages dont suck, and are quite reliable.

I personaly use/know these:

  - super famous tmux - terminal multiplexer
- you are probably aware of that one, handles lots of terminal sessions

  - gnu screen - terminal multiplexer
- older and poorer cousin of tmux

  - mpd - the music player daemon - basically music player 
- when spawned as it's own service outside of/before X it can keep music
  playing even as you are tweaking you xorg.conf :)
- can route music over fifos through network and make many amchines play
  same music

  - rxvt-unicode - uberterminal 
- this thing can operate as normal xterm-like term (process per session),
  or as daemon, when single process hosts all your terminals
- benefits are increased new terminal startup speed (on my current box,
  this is subsecond delay - helps when you treat terms as disposable
  "surfaces"), and supposedly memory conservation, as lots of data is shared
  between the windows

  - quassel - irc client
- irc client core runs as headless daemon, client present interface
- requires Qt and is quite heavy

  - irccd - irc client
- irc client, core runs as headless daemon, that can be scripted
- i used it originally for lua, but since it went js, i use old one

There are probably few others. Excluding screen and quassel, I use them daily.

Many other things can be "adapted" to daemon, for example aria2c downloader
supports xmlrpc interface. There is slew of bittorrent clients, that can be run
this way.

I make distinction though, that proper packages of this class,
make use of unix sockets by default (many things listen on TCP/IP only)
and deamon usercase is well thought out: 
  - support for foreground mode is builtin
- this foregorund is actually daemon foreground, with messages and, 
  not cli commands listener (so it's not "normal" program fake daemon)
  - there is dedicated client program to talk to daemon
  - you can configure client/server connection control points
  - the whole setup is documented and intended by author

Regarding "major" problem 1., that of crashing, rxvt-unicode is most "felt" when
it trips over. Fortunately it is incredibly stable - I have crash it maybe one
or two times in 7 years time frame, daily use. I usually have 10-100 open
terminals per xsession.

Supervisors are pretty great at taming and organizing these things.
I see you wrote articles about supervision (in post systemd world),
maybe there would be will to collect & categorise these user-level daemon tools
and provide more information on how to supervise them?

  eto

Re: GNU Emacs now runs in foreground

[Jean Louis]

Hello Jonathan,

Now when I use s6, I don't want to switch, maybe on some other
computers I can test the nosh. It looks like good system, especially
if you start providing such solutions for various daemons.


On Sat, Dec 03, 2016 at 11:33:51AM +, Jonathan de Boyne Pollard wrote:
> Jean Louis:
> 
> > emacs --new-daemon=NAME
> > 
> 
> I have added a new per-user service for this to nosh, ready for version 1.30
> .  So one just has to start the per-user service manager
> 
> # system-control start user@jlouis.target
> 
> then start the emacs server
> 
> $ system-control --user start emacs
> 
> Adjust its environment, if desired, in the conventional way
> 
> $ system-control --user set-service-env emacs DISPLAY :15.2
> 
>or (if /usr/local/sbin is on one's path)
> 
> $ rcctl set --user emacs DISPLAY :15.2

I see about adjusting environment. I guess that may be good, only
DISPLAY should not be necessary, it is daemon, and I start it without
display, and later also GNU Emacs running on X can access it, but also
from a console.

If I understand it well, in your system, you define services, and then
the service may be marked for start by user? And then it runs on each
boot by user?

Jean

Re: GNU Emacs now runs in foreground

[Jonathan de Boyne Pollard]

Jean Louis:


emacs --new-daemon=NAME



I have added a new per-user service for this to nosh, ready for version 
1.30 .  So one just has to start the per-user service manager


# system-control start user@jlouis.target

then start the emacs server

$ system-control --user start emacs

Adjust its environment, if desired, in the conventional way

$ system-control --user set-service-env emacs DISPLAY :15.2

   or (if /usr/local/sbin is on one's path)

$ rcctl set --user emacs DISPLAY :15.2

Re: GNU Emacs now runs in foreground

[Jean Louis]

On Thu, Dec 01, 2016 at 12:54:38PM -0500, Steve Litt wrote:
> On Thu, 1 Dec 2016 20:48:37 +0300
> Jean Louis  wrote:
> 
> > On Thu, Dec 01, 2016 at 12:41:18PM -0500, Steve Litt wrote:
> > > > 
> > > > Just before some time, emacs --daemon, would go into background,
> > > > so it was not feasible to control it with s6 scripts. Now
> > > > developers changed it, and it is possible to invoke multiple
> > > > instances by name, and still keep the daemon in foreground. In
> > > > that mode there is no interface to editor. Clients that access
> > > > the editor, show the interface.  
> > > 
> > > Fascinating! How do emacs clients communicate with the emacs daemon?
> > > Sockets?
> > > 
> > > How many other user programs might be used as daemons. What an
> > > interesting idea! For some reason, mplayer pops into my mind.  
> > 
> > I have a strange feeling that you are joking...
> 
> Not at all. You know mplayer can interact via a FIFO.
> 
> Seriously, I'm not joking. I'm always interested in new ways to use my
> computer.

By the way, interesting book there.

Back to topic. When emacs is daemon on my side, I start it before the
X, so I can even restart X, buffers are in memory. And I start editor
simply faster. It is huge, but it gives me everything I need. Actually
it is not an editor, more kind of environment of various tools.

Org Mode is one of good ways of writing text, that may be exported as
books, with the contents, and all. Add the front page and back page,
and you get professional typeset book without the external
service. Tip for you as author. http://orgmode.org it is built in.

Jean

Re: GNU Emacs now runs in foreground

[Steve Litt]

On Thu, 1 Dec 2016 20:48:37 +0300
Jean Louis  wrote:

> On Thu, Dec 01, 2016 at 12:41:18PM -0500, Steve Litt wrote:
> > > 
> > > Just before some time, emacs --daemon, would go into background,
> > > so it was not feasible to control it with s6 scripts. Now
> > > developers changed it, and it is possible to invoke multiple
> > > instances by name, and still keep the daemon in foreground. In
> > > that mode there is no interface to editor. Clients that access
> > > the editor, show the interface.  
> > 
> > Fascinating! How do emacs clients communicate with the emacs daemon?
> > Sockets?
> > 
> > How many other user programs might be used as daemons. What an
> > interesting idea! For some reason, mplayer pops into my mind.  
> 
> I have a strange feeling that you are joking...

Not at all. You know mplayer can interact via a FIFO.

Seriously, I'm not joking. I'm always interested in new ways to use my
computer.

SteveT



-- 
SteveT

Steve Litt 
November 2016 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz

Re: GNU Emacs now runs in foreground

[Jean Louis]

On Thu, Dec 01, 2016 at 12:41:18PM -0500, Steve Litt wrote:
> > 
> > Just before some time, emacs --daemon, would go into background, so it
> > was not feasible to control it with s6 scripts. Now developers changed
> > it, and it is possible to invoke multiple instances by name, and still
> > keep the daemon in foreground. In that mode there is no interface to
> > editor. Clients that access the editor, show the interface.
> 
> Fascinating! How do emacs clients communicate with the emacs daemon?
> Sockets?
> 
> How many other user programs might be used as daemons. What an
> interesting idea! For some reason, mplayer pops into my mind.

I have a strange feeling that you are joking...

Re: GNU Emacs now runs in foreground

[Steve Litt]

On Thu, 1 Dec 2016 20:28:46 +0300
Jean Louis  wrote:

> On Thu, Dec 01, 2016 at 12:05:31PM -0500, Steve Litt wrote:

> > OK, I'll byte.
> > 
> > I thought emacs was an editor that a human runs in the foreground to
> > edit files, so my reaction to this was "of course it runs in the
> > foreground!"
> > 
> > What am I missing?  
> 
> You are right, it is hard to figure out the context. That is for s6
> services, I am invoking editor as daemon, so that it may be accessed
> later by need.
> 
> Buffers remain in memory, and so the IRC, Jabber chat, various
> documents from which I yank parts of texts into emails, registers, the
> programming languages are invoked within the editor, and shells and
> other tools. Invoking single editor each time is a bit slower, than
> invoking it as client that accesses the daemon. And that way, all the
> goodies would be lost by each new invocation. Some people have
> multiple buffers over multiple days.
> 
> Just before some time, emacs --daemon, would go into background, so it
> was not feasible to control it with s6 scripts. Now developers changed
> it, and it is possible to invoke multiple instances by name, and still
> keep the daemon in foreground. In that mode there is no interface to
> editor. Clients that access the editor, show the interface.

Fascinating! How do emacs clients communicate with the emacs daemon?
Sockets?

How many other user programs might be used as daemons. What an
interesting idea! For some reason, mplayer pops into my mind.

Thanks!
 
SteveT

Steve Litt 
November 2016 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz

Re: GNU Emacs now runs in foreground

[Steve Litt]

On Thu, 1 Dec 2016 11:18:29 +0300
Jean Louis  wrote:

> The GNU Emacs now has got a new option:
> 
> emacs --new-daemon=NAME
> 
> that is running emacs daemon in foreground, obviously someone reacted
> since last time I wrote to the emacs mailing list. It is in the
> development version or git.

OK, I'll byte.

I thought emacs was an editor that a human runs in the foreground to
edit files, so my reaction to this was "of course it runs in the
foreground!"

What am I missing?

Thanks,
 
SteveT

Steve Litt 
November 2016 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz

GNU Emacs now runs in foreground

[Jean Louis]

The GNU Emacs now has got a new option:

emacs --new-daemon=NAME

that is running emacs daemon in foreground, obviously someone reacted
since last time I wrote to the emacs mailing list. It is in the
development version or git.

http://savannah.gnu.org/projects/emacs/

That is great news for those who use s6-rc and wish to run emacs.

No need any more for tricks with "screen" like below:

#!/bin/execlineb -P
if { s6-test -d /home/data1/protected/Work }
s6-setuidgid admin
backtick -n HOME { homeof admin }
backtick -n PATH { echo
"/home/data1/protected/perl5/bin:/home/data1/protected/bin:/bin:/usr/bin:/opt/texlive/2015/bin/x86_64-linux:/opt/jdk/bin:/opt/qt4/bin:/opt/qt5/bin"
 }
backtick -n LC_ALL { echo "en_US.UTF-8" }
/usr/bin/screen -l -S emacs -D -m --
/usr/bin/emacs --user admin --chdir /home/data1/protected

Jean Louis