From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Improving Shepherd Date: Fri, 09 Feb 2018 14:26:21 +0100 Message-ID: <87y3k21egy.fsf@gnu.org> References: <871si8bc5g.fsf@zancanaro.id.au> <877errn23f.fsf@zancanaro.id.au> <871shzeg8m.fsf@gnu.org> <87d11jh1lv.fsf@zancanaro.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ek8hA-0002MI-0V for guix-devel@gnu.org; Fri, 09 Feb 2018 08:26:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ek8h6-0003Cn-MC for guix-devel@gnu.org; Fri, 09 Feb 2018 08:26:28 -0500 Received: from hera.aquilenet.fr ([2a0c:e300::1]:55286) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ek8h6-0003C5-BB for guix-devel@gnu.org; Fri, 09 Feb 2018 08:26:24 -0500 In-Reply-To: <87d11jh1lv.fsf@zancanaro.id.au> (Carlo Zancanaro's message of "Tue, 06 Feb 2018 02:56:12 +1100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Carlo Zancanaro Cc: guix-devel@gnu.org Carlo Zancanaro skribis: > Hey Ludo, > > On Mon, Feb 05 2018, Ludovic Court=C3=A8s wrote: >>> User services - Alex has already sent a patch to the list to allow >>> generating user services from the Guix side. The idea is to >>> generate a >>> Shepherd config file, allowing a user to invoke shepherd manually >>> to >>> start their services. A further extension to this would be to have >>> something like systemd's "user sessions", where the pid 1 Shepherd >>> automatically starts a user's services when they log in. >> >> After replying to Alex=E2=80=99 message, I realized that we could just as >> well >> have a separate =E2=80=9Cguix service=E2=80=9D or similar tool to take c= are of this? >> >> This needs more thought (and perhaps taking a look at systemd user >> sessions, which I=E2=80=99m not familiar with), but I think Alex=E2=80= =99 approach >> is a >> good starting point. > > We were thinking it might work like this: > - services->package constructs a package which places a file in the > profile containing the necessary references > - pid 1 shepherd listens to elogind login/logout events, and starts > the services when necessary > > Admittedly this isn't the nicest way for it to work, but it might be a > good starting point. Yes, sounds reasonable. > There were some discussions on the list a while ago about how to have > `guix environment` automatically start services, too, so I wonder what > overlap there could be there. Although maybe environment services (in > containers) have more in common with system services than user > services. That=E2=80=99s a separate topic I think, but I agree it=E2=80=99d be useful. >> Currently shepherd monitors SIGCHLD, and it=E2=80=99s not supposed to mi= ss >> those; in some cases it might handle them later than you=E2=80=99d expec= t, >> which >> means that in the meantime you see a zombie process, but otherwise >> it >> seems to work. >> >> ISTR you reported an issue when using =E2=80=98shepherd --daemonize=E2= =80=99, right? >> Perhaps the issue is limited to that mode? > > I no longer use the daemonize function. My user shepherd runs "in the > foreground" (it's started when my X session starts), so it's not > that. Jelle fixed the problem I was having by delaying the SIGCHLD > handler registration until it's needed. It is still buggy if a process > is started before the daemonize command is given to root service, > though. > > If you try running "emacs --daemon" with "make-forkexec-constructor" > (and #:pid-file, and put something in your emacs config to make it > write out the pid) you should be able to reproduce what I am > seeing. If you kill emacs (or if it crashes) then shepherd continues > to report that it is started and running. When I look at htop's output > I can also see that my emacs process is not a child of my shepherd > process. > > I would like to add a --daemon/--daemonize command line argument to > shepherd instead of the current "send the root service a daemonize > message". I think the use cases of turning it into a daemon later are > limited, and it just gives you an additional way of shooting yourself > in the foot. Also a separate topic ;-), but if you still experience a bug, please report it and see whether you can provide a reduced test case to reproduce it. >> I=E2=80=99d really like to see that happen. I=E2=80=99ve become more fa= miliar with >> Fibers, and I think it=E2=80=99ll be perfect for the Shepherd (and we=E2= =80=99ll fix >> the >> ARM build issue, no doubt.) > > I'm not going to put much time/effort into this until we have fibers > building on ARM. Hopefully it=E2=80=99s nothing serious: Fibers doesn=E2=80=99t rely on anyt= hing architecture-specific. > I think these changes are likely to break shepherd's config API, > too. I=E2=80=99m not sure. We may be able to keep the exact same API. At least that=E2=80=99s what I had in mind for the first Fibers-enabled Shepherd. > In particular, with higher levels of concurrency I want to move the > mutable state out of objects. The only piece of mutable state is the =E2=80=98running=E2=80=99 value. We= can make that an =E2=80=9Catomic box=E2=80=9D, and users won=E2=80=99t even notice. >> It seems that signalfd(2) is Linux-only though, which is a bummer. >> The >> solution might be to get over it and have it implemented on >> GNU/Hurd=E2=80=A6 >> (I saw this discussion: >> ; >> I >> suspect it=E2=80=99s within reach.) > > Failing that, could we have our signal handlers just convert the > signal to a message in our event loop? Yes, they could send a message on a Fibers channel. Thanks, Ludo=E2=80=99.