Re: [Nicolas Graves] [PATCH v6 01/10] rde: emacs: Start emacs in --daemon mode, with shepherd and pid-file

[Nicolas Graves via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org>]

On 2024-05-12 12:36, Eli Zaretskii wrote:

>> From: Nicolas Graves <ngraves@ngraves.fr>
>> Cc: monnier@iro.umontreal.ca, ludo@gnu.org, emacs-devel@gnu.org,
>>  andrew@trop.in, guix-devel@gnu.org, bjorn.bidar@thaodan.de,
>>  rudi@constantly.at, felix.lechner@lease-up.com
>> Date: Sun, 12 May 2024 09:50:06 +0200
>> 
>> On 2024-05-12 09:29, Eli Zaretskii wrote:
>> 
>> > Thanks.  What was the motivation for this, again?
>> 
>> A light summary (all is in the preceding exchanges in the mailing list):
>> 
>> - Ludovic Courtès suggested this change because linking with systemd is
>> unnecessary (very light usage), and increases the attack surface.
>> 
>> - Rudolf Schlatte highlights that Lennart Poettering says that the
>> notify protocol is stable and independent of libsystemd.
>>           https://mastodon.social/@pid_eins/112202687764571433
>>           https://mastodon.social/@pid_eins/112202696589971319
>>   This mastondon thread itself contains a lot of info/answers about
>>   this, including examples of similar work on other projects:
>>   - https://github.com/FRRouting/frr/pull/8508
>>   - https://github.com/OISF/suricata/pull/10757
>>   Lennart Poettering also says that the protocol has been stable for a
>>   decade and will surely be for at least another decade.
>> 
>> This should also answer the worry about significant maintenance.
>
> I'm sorry, but I'm wary of believing such assertions, especially when
> systemd is involved.  E.g., what's to prevent people from asking us to
> support the various forks of systemd as well?

Don't they also support this precise protocol?

Originally this thread was precisely about some limitations about
emacs's integration with GNU shepherd, exposing a "manual" pid-file
solution I found, and Ludovic answering "great, but look GNU shepherd
can emulate notify protocol's server side and GNU emacs can do it on the
client side". What I get from that is that systemd is so ubiquitously
used that even GNU Shepherd needed to emulate systemd's notify protocol
to properly manage some services, this protocol is probably already
emulated in most init system (is it?). In my own experience, it's indeed
simpler to rely on it rather than manually implementing proper
emacs-shepherd integration.

> Reimplementing everything in-house doesn't scale, definitely not in a
> project as large as Emacs.  So the argument about smaller attack
> surface doesn't really convince me.  Emacs uses quite a lot of
> external libraries to the benefit of our users, and that will not
> change any time soon.

Lennart himself wrote "if all you want is sd_notify() then don't bother
linking to libsystemd, since the protocol is stable and should be
considered the API", I'm (with my biases) more worried about "if all you
want" and what happens if users ask for deeper integration with systemd
than these two functions than about systemd's stability promise.

One example is what I did with my pid-file emacs-shepherd integration :
be able to notify (in the sense of libnotify, not systemd) when server
has started but is not ready yet. This could be done with some smart use
of sd_notify_reloading, and would require the vendoring of this other
function (although this one is provided as such by Lennart too ; but any
deeper use (I can't find an example though) might be harder to implement).

I'm not going to push much for this, currently rewriting the patch, will
make that working again with recommended changes. If maintainers get
convinced and licensing is ok, use it. If Guix or some other distro want
to use it as a vendored patch, fine (indeed it doesn't make sense on
Guix to pass elogind as an input for this). I just wrote that after
Stefan's suggestion, and after seeing that the actual code is basically
two C functions, I'm not actively pushing for it.

>> What I'm less confident about is edge cases as I highlighted earlier
>> (are there cases where systemd's safe_atoi is necessary compared to
>> strtol ? Is it fine if LISTEN_FDS is set but LISTEN_PID unset, or
>> should be check for LISTEN_PID definition too ?)
>
> This is exactly the kind of maintenance burden I'm concerned about:
> who will help us answer these questions, now and in the future?  We
> cannot rely on having systemd experts on board at all times.

I'll add a tiny check to also verify that LISTEN_PID is set.

The first question is the kind of questions that come up when adapting
foreign code, but when strictly reading the protocol, it should be
fine, the point is to parse LISTEN_FDS.

>> >> > - The sd_notify code is taken from
>> >> > https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes
>> >
>> > I'm not sure what would be the legal aspects of such code borrowing.
>> 
>> The code is given as MIT-0, hence also the two different licenses for
>> the two functions sd_notify and sd_is_socket. Not an expert on licenses
>> either, but with a proper flag about what this function's license is, I
>> guess it should be fine, since other projects also do that.
>
> The license is only half of the problem.  Every non-trivial
> contribution to Emacs must have its copyright assigned to the FSF,
> because the FSF is in charge of protecting the Emacs sources,
> something that only the copyright holder can do, at least in some
> countries.  You will need to assign the copyright as well (a
> relatively simple procedure of filling a form and emailing it), but if
> the code is not yours, you cannot assign its copyright.

Don't emacs have some C functions coming mainly from other codebases?
How is it handled in this case?




I have a development question. Where should be the functions
declaration header? There are specific to gnu-linux/aix/hpux. Thanks.




NB. In emacs's configure.ac, the note about finding which libsystemd
version is the first supported, with 222 truly working, has an answer in 
https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes
Interfaces used have been introduced in 217. Requires a test, but that
is almost certainly the answer.

-- 
Best regards,
Nicolas Graves