Uoti Urpala writes:
> BTW it's worth noting that in the typical daemon case where "readiness"
> means the listening socket is ready to accept requests, the right way to
> convert the daemon to a new API is to use socket activation, which
> removes the need for separate start-up completion notific
On Sat, 2013-12-21 at 08:49 -0800, Russ Allbery wrote:
> Tollef Fog Heen writes:
> > sd-daemon.c is also intentionally designed to not have dependencies on
> > the rest of the systemd source and to be portable to non-linux
> > architectures too (but basically just stubs then) just so people can pu
]] Russ Allbery
> Tollef Fog Heen writes:
>
> > sd-daemon.c is also intentionally designed to not have dependencies on
> > the rest of the systemd source and to be portable to non-linux
> > architectures too (but basically just stubs then) just so people can put
> > the file in their source and
Tollef Fog Heen writes:
> sd-daemon.c is also intentionally designed to not have dependencies on
> the rest of the systemd source and to be portable to non-linux
> architectures too (but basically just stubs then) just so people can put
> the file in their source and not have to fiddle with check
]] Russ Allbery
> Ian Jackson writes:
> > Russ Allbery writes:
>
> >> I'd like to see both of them support systemd's method, since it's
> >> extensible and provides more general functionality. I think the
> >> benefit of support for SIGSTOP is marginal; adding sd_notify calls is
> >> not that
Hi Andreas,
Le samedi 21 décembre 2013 à 08:48 +0100, Andreas Barth a écrit :
> 1. Does systemd (or a part of the systemd project) need to be the
> single cgroup writer and if so, why?
It does not… so far. The only thing currently required is for cgroups
consumers to adhere to the shared guideli
6 matches
Mail list logo
