Re: GNU Emacs now runs in foreground
Martin "eto" Misuth: exec mpd --no-daemon /usr/home/eto/.config/mpd/mpd.conf Jonathan de Boyne Pollard: 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: I use with my own scripts, but for things having local /etc, /usr/local/etc alternatives I prefer those. That's not /usr/local/etc/ . It's /usr/home/eto/.config/ . $ system-control --user find mpd /usr/home/JdeBP/.config/service-bundles/services/mpd $ system-control --user cat mpd start:#!/bin/nosh start:#Start file generated from ./mpd.socket start:foreground mkdir -- /run/user/JdeBP/mpd ; start:true stop:#!/bin/nosh stop:#Stop file generated from ./mpd.service stop:foreground rm -r -f -- /run/user/JdeBP/mpd/ ; stop:true run:#!/bin/nosh run:#Run file generated from ./mpd.socket run:#Music Player socket used by JdeBP run:local-stream-socket-listen --systemd-compatibility --backlog 5 --pass-credentials /run/user/JdeBP//mpd/socket run:./service service:#!/bin/nosh service:#Service file generated from ./mpd.service service:#Music Player daemon run by JdeBP service:musicpd --no-daemon --stderr --stdout --verbose ./mpd.conf restart:#!/bin/sh restart:#Restart file generated from ./mpd.service restart:exec true # ignore script arguments $
Re: GNU Emacs now runs in foreground
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
> 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 the standard error stream." [1] But what do I know. [1] https://www.postgresql.org/docs/9.6/static/app-postgres.
Re: GNU Emacs now runs in foreground
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. This is a policy decision that is historically the daemontools way of configuring services, but there are arguments for and against it. I don't know how nosh organizes its service directories, but with s6 and especially s6-rc I have a strong argument in favor of keeping configuration (and other read-only data) _outside_ of the service directory: the service directory can live in RAM. 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. -- Laurent
Re: GNU Emacs now runs in foreground
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
> 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 - including s6's one - observing behaviour of reparenting under init fo
Re: GNU Emacs now runs in foreground
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
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
On Tue 2016-12-06 07:15:49 -0500, Jonathan de Boyne Pollard wrote: > 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. fwiw, dbus-user-session supports at most one graphical session concurrently. from "apt-cache show dbus-user-session: Package: dbus-user-session […] Multiple graphical sessions per user are not currently supported in this mode; as a result, it is particularly suitable for gdm, which responds to requests to open a parallel graphical session by switching to the existing graphical session and unlocking it. […] > 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. in the dbus-user-session model, there can be 0 or 1 attached $DISPLAYs -- this is different from "exactly 1 $DISPLAY" but it's hardly difficult to decide what the $DISPLAY should be. it's either the empty string, or it's the connected $DISPLAY. > In practice, thus, the implementation of the user-wide client-server > idea is half-hearted and flawed in this respect. Yet surely there are some user-wide services that don't need DISPLAY at all, and would be happy to run per-user? --dkg
Re: GNU Emacs now runs in foreground
On Tue, Dec 06, 2016 at 10:44:11AM -0500, Steve Litt wrote: > 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. No GNOME here, no KDE, no such things, just to confirm, I am best without it. > 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. I would like to kick it out, if I could, I just don't know how. > To me, Linux is and should remain a DIY accessible OS, and that > requires shunning all things FreeDesktop.Org. That was made by corporations for corporations and their interests. They don't do anything in my specific interest. Like who said I need ~/Desktop? I don't need it. But applications are creating it automatically. Who says I want to keep ~/Video ~/Music and such? Or that I want to open files with xdg-open? That type of control of how commands shall be executed and what directories/folders shall users have on their systems, I have tried to escape back in 1999, when I switched from Windows. And now we see the same pattern. Jean Louis
Re: GNU Emacs now runs in foreground
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
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
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
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
> 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
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
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
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
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
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
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
On Thu, Dec 01, 2016 at 12:05:31PM -0500, Steve Litt wrote: > 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? 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. Jean
Re: GNU Emacs now runs in foreground
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
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