* License : BSD
Programming Lang: Python
Description : Cython-based wrapper on top of libsystemd
pystemd is a thin Cython-based wrapper on top of libsystemd, focused on
exposing the dbus API via sd-bus in an automated and easy to consume way.
It allows talking to systemd over dbus from
Hello,
Jonathan de Boyne Pollard, on Thu 01 Sep 2016 08:47:44 +0100, wrote:
> >You have forgotten about the existence of Debian Hurd. (-:
> >
> >* https://jdebp.eu./FGA/hurd-daemons.html#proc
>
> >The Hurd precisely tries to expose things as files.
> >
> Not in this case. I pointed earlier to t
Dmitry Bogatov:
Thanks history, we have pid files, not `libpid' to talk to `pidd'.
Jonathan de Boyne Pollard:
You have forgotten about the existence of Debian Hurd. (-:
* https://jdebp.eu./FGA/hurd-daemons.html#proc
Samuel Thibault:
The Hurd precisely tries to expose things as files.
]] Jonathan de Boyne Pollard
> Russ Allbery:
>
> > I think that... says the same thing I said?
> >
> Read again, and let your eye dwell upon Laurent Bercot's name this
> time. (-: The world has changed since 2014 and the Debian systemd
> packaging Hoo-Hah, and I've been keeping tabs.
s6 doesn
Russ Allbery:
I think that... says the same thing I said?
Read again, and let your eye dwell upon Laurent Bercot's name this
time. (-: The world has changed since 2014 and the Debian systemd
packaging Hoo-Hah, and I've been keeping tabs.
* https://jdebp.eu./FGA/unix-daemon-readiness-proto
y're not something anyone
> would want to use voluntarily.
I agree, that pid-files are not blessing, especially when we have
runit/daemontools/s6, which makes them unneeded.
But if I had to choose between pidfiles or linking to `libpid' to talk
with `pidd' (especially, if it is
[2016-08-30 08:55] Jonathan de Boyne Pollard
>
> part text/plain 198
> Dmitry Bogatov:
>
> > Thanks history, we have pid files, not `libpid' to talk to `pidd'.
> >
> You have forgotten about the existence of Debian Hurd. (-:
I like Hurd idea, but I was talking about Linux
Jonathan de Boyne Pollard, on Tue 30 Aug 2016 08:55:26 +0100, wrote:
> >Thanks history, we have pid files, not `libpid' to talk to `pidd'.
> >
> You have forgotten about the existence of Debian Hurd. (-:
The Hurd precisely tries to expose things as files.
Samuel
Dmitry Bogatov:
Thanks history, we have pid files, not `libpid' to talk to `pidd'.
You have forgotten about the existence of Debian Hurd. (-:
* https://jdebp.eu./FGA/hurd-daemons.html#proc
safely because the original daemon is long-gone, the PID space has
wrapped, and now that PID is pointing to sshd and gets happily killed by
something that blindly trusts the PID file. They're not something anyone
would want to use voluntarily.
> I would be interested to know of more selling
d' to talk to `pidd'.
I would be interested to know of more selling points of libsystemd,
but discussion how to implement them in simple way does not belong to
debian-devel, but to upstream projects lists.
--
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io
Vincent Bernat writes:
> ❦ 29 août 2016 05:00 CEST, Russ Allbery :
>> upstart supports a similar mechanism via the -Z flag, but it's (IMO) a
>> little less clean: the process sends itself a SIGSTOP when it's ready,
>> and then lets the init system send it a SIGCONT. This does work, but I
>> do
Jonathan de Boyne Pollard
writes:
> Russ Allbery:
>> All other init systems except upstart [...]
> Psst!
> * https://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html#Choice
I think that... says the same thing I said? At least the only ones I see
there are systemd and a proposal for
Dmitry Bogatov writes:
> I can understand this need, although never needed it myself.
> But implementation makes me sad. Instead of creating UNIX-way solution
> (create /var/run/foo.ready, when you are ready?), it does the worst
> thing I can imagine.
If communicating with another local daemon
[2016-08-28 20:00] Russ Allbery
>
> part text/plain3207
> Dmitry Bogatov writes:
>
> > Not to start flame or to advertize anything/anyone, but why to integrate
> > with 'runit' init system, your program should support foreground
> > operation and logging on stdout, and to in
❦ 29 août 2016 05:00 CEST, Russ Allbery :
> upstart supports a similar mechanism via the -Z flag, but it's (IMO) a
> little less clean: the process sends itself a SIGSTOP when it's ready, and
> then lets the init system send it a SIGCONT. This does work, but I don't
> like it as much; pausing f
Russ Allbery:
All other init systems except upstart [...]
Psst!
* https://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html#Choice
eople maintain for you), which I think is
a cleaner solution. The point is admittedly arguable.
There's other stuff, like socket activation, that can be useful in some
situations, but the explicit notification protocol was what sold me on
adding optional libsystemd dependencies to the daemon
[2016-08-28 06:26] Adam Borowski
>
> part text/plain2020
> On Sat, Aug 27, 2016 at 10:33:36AM +0300, Dmitry Bogatov wrote:
> > > > I hugely support idea of dynamically loading libsystemd.
> > >
> > > Please don't, no. Wh
On Sun, Aug 28, 2016 at 02:21:47PM +0100, Jonathan de Boyne Pollard wrote:
> Simon McVittie:
> >You mean like libsystemd, which looks in /run to see whether systemd is in
> >use, talks to it if it is, and returns some suitable error code (-ENOSYS?)
> >if it isn't? :-)
&
❦ 28 août 2016 15:21 CEST, Jonathan de Boyne Pollard
:
>> You mean like libsystemd, which looks in /run to see whether systemd
>> is in use, talks to it if it is, and returns some suitable error
>> code (-ENOSYS?) if it isn't? :-)
>>
> Here's interesting f
ally, they might. But this is a facet of the Debian build system
> in general, and not specific to systemd.
It's more egregious in the case of libsystemd than in many other cases,
because of the purpose of the package and the rarity with which changes
related to that package will appear
Simon McVittie:
You mean like libsystemd, which looks in /run to see whether systemd
is in use, talks to it if it is, and returns some suitable error code
(-ENOSYS?) if it isn't? :-)
Here's interesting for you. (-:
Here's libsystemd and Arturo Borrero Gonzalez'
The Wanderer:
IMO this level of integration between things which are not mutually
interdependent is a minor bug in itself, but none of the maintainers
are going to agree with me on that.
Actually, they might. But this is a facet of the Debian build system in
general, and not specific to sy
On Sat, Aug 27, 2016 at 10:33:36AM +0300, Dmitry Bogatov wrote:
> > > I hugely support idea of dynamically loading libsystemd.
> >
> > Please don't, no. While I do think packages should keep sysvinit
> > support as long as it continues to work and doesn't make
e from recompiling
things to remove small dependencies like libsystemd over your entire
lifetime.
Premature optimization is the root of all evil, to quote Knuth.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
On Sat, Aug 27, 2016 at 07:36:02AM -0400, The Wanderer wrote:
> There is one minor/cosmetic downside of libsystemd as currently
> provided, however: the apt-listchanges changelog.
>
> The only '*systemd*' package which I have installed is libsystemd0.
> However, whenever
On 2016-08-27 at 06:26, Andrew Shadura wrote:
> On 27 August 2016 at 10:33, Dmitry Bogatov wrote:
>
>> Like compat package, which provides libsystemd.a static library
>> and headers, that mirrors interface of libsystemd. This library
>> would forward call to actual libs
AppArmor and SELinux at the same
> time. Oddly enough, nobody has complained about that, only about
> libsystemd...
Thanks for hint.
> In particular, changing programs to dlopen libsystemd is actively harmful -
> it is not just a waste of effort, it would also defeat Debian's
>
On Sat, 27 Aug 2016 at 10:33:36 +0300, Dmitry Bogatov wrote:
>
> > > > * conntrackd & systemd are very good integrated (using libsystemd)
> > >
> > > I hugely support idea of dynamically loading libsystemd.
> >
> > Please don't, no. While I
On Sat, Aug 27, 2016 at 10:33:36AM +0300, Dmitry Bogatov wrote:
> > > I hugely support idea of dynamically loading libsystemd.
> >
> > Please don't, no. While I do think packages should keep sysvinit
> > support as long as it continues to work and doesn't make
> > > * conntrackd & systemd are very good integrated (using libsystemd)
> >
> > I hugely support idea of dynamically loading libsystemd.
>
> Please don't, no. While I do think packages should keep sysvinit
> support as long as it continues to work and do
Dmitry Bogatov wrote:
> Arturo Borrero Gonzalez wrote:
> > * conntrackd & systemd are very good integrated (using libsystemd)
>
> I hugely support idea of dynamically loading libsystemd.
Please don't, no. While I do think packages should keep sysvinit
support as long
On 24/07/14 12:16, Marco d'Itri wrote:
> This package provides a dummy libsystemd-daemon-dev binary package on
> kfreebsd-* and hurd-* systems.
>
> The purpose of this package is to allow other packages to
> unconditionally build-depend depend on libsystemd-daemon-dev, rem
This package provides a dummy libsystemd-daemon-dev binary package on
kfreebsd-* and hurd-* systems.
The purpose of this package is to allow other packages to
unconditionally build-depend depend on libsystemd-daemon-dev, removing the
need for ifdefs and configure-time checks for the library
35 matches
Mail list logo
