Re: [systemd-devel] pid 1 memlock setting configurable?

[Lennart Poettering]

On Do, 23.05.19 07:32, Kees Bos (cornelis@gmail.com) wrote:

> Hi all,
>
> I couldn't find it with google, and before digging in the code just a
> quick question. Probably someone knows it in the top of h(is|er)
> head...
>
> It seems that systemd drops rlimit_memlock on startup. Correct? And if
> so, is it configurable?

No. It actually raises it to 64M if it can:

https://github.com/systemd/systemd/blob/master/src/core/main.c#L1380

Before doing so it will save the original setting though and that's
what it tries to pass to services invoked as default too. Thus,
RLIMIT_MEMLOCK should really just be bumped for PID 1 itself, and only
if privileges allow.

> Explanation for the question:
> In an unprivileged container I can set the memlock config lower than
> 16MB (16777216 bytes), but not higher. That is, i can configure it, but
> effectively the systemd process (pid 1) will never have a limit higher
> than 16MB. Since it's an unprivileged container (and thus a fake 'root'
> user), that limit also becomes the max for all spawned processes
> (including services).

I am not sure how precisely rlimits are affected by userns, but I'd
guess you can't set rlimits higher in it than what they are set in the
lowest process outside of the userns, but I don't really know...

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] interacting with logind to detect user idle time

[Germano Massullo]

I have sent the following message to various desktop environment mailing lists

SUBJECT: Proposal: passing user idle time to systemd-logind
KDE Plasma: https://mail.kde.org/pipermail/plasma-devel/2019-May/098194.html
GNOME: https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00088.html
XFCE https://mail.xfce.org/pipermail/xfce4-dev/2019-May/032257.html
LXDE: https://sourceforge.net/p/lxde/mailman/message/36674273/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Node.js sd-notify module visibility

[Rory Bradford]

Hi,

I actively maintain a Node.js module "sd-notify" available on GitHub
(https://github.com/roryrjb/sd-notify) and npm
(https://www.npmjs.com/package/sd-notify) that has been contributed to
and is being used by others. As the name suggests it binds to
sd_notify_* functions.

It would be nice to be listed alongside other language bindings on this
page https://www.freedesktop.org/wiki/Software/systemd/ if possible,
especially as it is actively maintained. I don't know if the other
Node.js modules are still maintained or just haven't needed any
development for a while, but there doesn't seem to have been any
activity for a number of years.

Also I don't know if the projects listed in the GitHub organisation only
reflect those of official systemd contributors/developers but moving my
repo out into that namespace would be awesome and provide even more
community scrutiny.

Regards,

Rory (a happy systemd user and ecosystem contributor).




pEpkey.asc
Description: application/pgp-keys
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Q: Wants and WantedBy links in generated units and circular dependencies

[Ulrich Windl]

Hi!

After seeing that systemd generators are run as the very first step in
systemd's life (deduced from the timestamps), I quit the idea of using them,
and started to use another sort of generator:

I have a generator target, that creates another target and a few service
targets.
The interesting point is circular dependencies for the generated units, and
I'd like to ask if the following would work:

I need to enable a generated target to get ist wants-links installed; likewise
the generated service units need to be enabled to get the wants link from the
target to the service.
As my generator created the service units first, then the target unit which
"Wants" the service units.
The idea is that starting the soingle target unit will start all depending
service units.

So far that is without enabling. I wonder whether I can enable the service
units that are "WantedBy" the target unit _before_ the target unit was actually
generated.
If that doesn't work, I'll need a two-pass approach.

For history, one of the odd things in systemd v228 is this:
 # systemctl status iotwatch.target
● iotwatch.target
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
# systemctl enable iotwatch.target   ### thios command must do something
magic!
# systemctl status iotwatch.target
● iotwatch.target - iotwatch I/O performance monitor
   Loaded: loaded (/run/systemd/system/iotwatch.target; enabled; vendor
preset: disabled)
   Active: inactive (dead)
 Docs: man:iotwatch@.service(8)
   man:iotwatch-generator(8)


So it seems I must enable units just to be able to query whether they are
enabled...???

Regards,
Ulrich


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Node.js sd-notify module visibility

[Zbigniew Jędrzejewski-Szmek]

On Thu, May 23, 2019 at 09:25:02AM +0100, Rory Bradford wrote:
> Hi,
> 
> I actively maintain a Node.js module "sd-notify" available on GitHub
> (https://github.com/roryrjb/sd-notify) and npm
> (https://www.npmjs.com/package/sd-notify) that has been contributed to
> and is being used by others. As the name suggests it binds to
> sd_notify_* functions.
> 
> It would be nice to be listed alongside other language bindings on this
> page https://www.freedesktop.org/wiki/Software/systemd/ if possible,
> especially as it is actively maintained.
Links have been added.

> Also I don't know if the projects listed in the GitHub organisation only
> reflect those of official systemd contributors/developers but moving my
> repo out into that namespace would be awesome and provide even more
> community scrutiny.
I sent you an invitation for a new @systemd/nodejs team. Once you accept
that, you should be able to move your project under the systemd umbrella.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Node.js sd-notify module visibility

[Rory Bradford]

Many thanks!

The repo has been moved.

On 23/05/2019 10:04, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, May 23, 2019 at 09:25:02AM +0100, Rory Bradford wrote:
>> Hi,
>>
>> I actively maintain a Node.js module "sd-notify" available on GitHub
>> (https://github.com/roryrjb/sd-notify) and npm
>> (https://www.npmjs.com/package/sd-notify) that has been contributed to
>> and is being used by others. As the name suggests it binds to
>> sd_notify_* functions.
>>
>> It would be nice to be listed alongside other language bindings on this
>> page https://www.freedesktop.org/wiki/Software/systemd/ if possible,
>> especially as it is actively maintained.
> Links have been added.
>
>> Also I don't know if the projects listed in the GitHub organisation only
>> reflect those of official systemd contributors/developers but moving my
>> repo out into that namespace would be awesome and provide even more
>> community scrutiny.
> I sent you an invitation for a new @systemd/nodejs team. Once you accept
> that, you should be able to move your project under the systemd umbrella.
>
> Zbyszek


pEpkey.asc
Description: application/pgp-keys
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Node.js sd-notify module visibility

[Zbigniew Jędrzejewski-Szmek]

On Thu, May 23, 2019 at 10:11:32AM +0100, Rory Bradford wrote:
> Many thanks!
> 
> The repo has been moved.

Cool, welcome ;)
I updated https://www.freedesktop.org/wiki/Software/systemd/ to match.
Let us know if you want to add more maintainers to the nodejs group.

Zbyszek

> 
> On 23/05/2019 10:04, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, May 23, 2019 at 09:25:02AM +0100, Rory Bradford wrote:
> >> Hi,
> >>
> >> I actively maintain a Node.js module "sd-notify" available on GitHub
> >> (https://github.com/roryrjb/sd-notify) and npm
> >> (https://www.npmjs.com/package/sd-notify) that has been contributed to
> >> and is being used by others. As the name suggests it binds to
> >> sd_notify_* functions.
> >>
> >> It would be nice to be listed alongside other language bindings on this
> >> page https://www.freedesktop.org/wiki/Software/systemd/ if possible,
> >> especially as it is actively maintained.
> > Links have been added.
> >
> >> Also I don't know if the projects listed in the GitHub organisation only
> >> reflect those of official systemd contributors/developers but moving my
> >> repo out into that namespace would be awesome and provide even more
> >> community scrutiny.
> > I sent you an invitation for a new @systemd/nodejs team. Once you accept
> > that, you should be able to move your project under the systemd umbrella.
> >
> > Zbyszek

> pub  3072R/1EC95E98 2019-04-21 Rory Bradford 
> 
> sub  3072R/5899FC77 2019-04-21 [expires: 2020-04-20]

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-bus: Enabling free-standing, bus-independent plain messages

[Stanislav Angelovič]

Hi Lennart,

Sorry for a bit late reply, I've been quite busy recently.

> So we could readd the ability to create a bus message with a NULL bus,
> but I am a bit concerned that people then always pass NULL which might
> ultimately result in constant remarshalling if the message is
> eventually enqueued on a real bus. When you put together a message it
> actually matters which bus connection you do that for...

My proposal is that we would allow passing NULL bus ptr only for
`sd_bus_message_new` function. And such a message would be disallowed from
enqueuing. In functions that need real bus ptr we might place an assert
that bus != NULL. In a limited set of functions, which I mentioned in
previous e-mail (`sd_bus_message_seal` for example), we would allow bus ==
NULL.

> Note that message behaviour and so on depends in sometimes subtle and
sometimes not
> so subtle ways on the bus connection used, i.e. whether we are talking
> to a real bus or not, and so on. I am not to keen of making this
> completely independent I must admit...
>
> What's the usecase for using bus message as general marshalling
> storage anyway? Can you elaborate?

I provided a use case example a few years ago in
https://lists.freedesktop.org/archives/systemd-devel/2016-
November/037929.html, but I'll elaborate more.

sdbus-c++ provides such a generic layer of abstraction that its clients
don't work with messages but call D-Bus methods as-if it was a local
operation, using native types. For that, all D-Bus types have their native
representation. A D-Bus array is represented as std::vector. A D-Bus string
is std::string. And for D-Bus variant there is custom sdbus::Variant class
that needs to be able to store whatever D-Bus types. So for example, for a
method `doSomething` that takes a D-Bus string and an int, and returns an
array of variants, sdbus-c++ generates something like
`std::vector doSomething(std::string str, int i);`. Clients
call this method, and sdbus-c++ does all the job -- it creates a method
call message, serializes data into it, sends the message, receives the
reply message, and automatically deserializes its contents into
std::vector. But variant is special. When deserializing,
sdbus-c++ is unaware what real type is under each variant, but it still
must be able to get a given variant out of the message and store it in the
vector to be returned. This is done by `sd_bus_message_copy` of just that
variant message part. It cannot do `sd_bus_message_enter_container` and
`sd_bus_message_read` directly, because sd-bus API requires signature of
underlying variant contents, and this is what sdbus-c++ has no idea about
at this point. It's the client who knows, so the client then at a later
point, in his own code, asks for an object of specific type from that
Variant, like so `double d = variant.get()`. Here is when
`sd_bus_message_enter_container` and `sd_bus_message_read` on variant
message are called, so the deserialization from variant message takes
place. It's something like 2-step deserialization -- but only with
variants, they are special in that.

Of course, our first idea was to use C++ type-erasure technique employed by
e.g. std::any to implement the Variant class. This works fine when we
construct Variant from a native type. But when we need to create Variant
out of a part of incoming D-Bus message, like in the example of method
reply message above, we are stuck. The code would be very complex,
practically impossible to write, due to conversion of run-time combinations
of D-Bus types to static, compile-time type representations (vectors, maps
of various keys and values that could maps again etc...). Hence, using
sd-bus message as an underlying implementation of Variant class is the
simplest and most reasonable solution; we are simply using the concept that
is implemented in sd-bus already. We can easily create Variant out of a
native type (by serializing the value into underlying message), create
Variant out of existing message (by copying the message part into
underlying message), and read data back from Variant (by reading the
underlying message).

> A compromise might be that we readd a concept of allowing
> bus-independent messages to be generated again (i.e. pass NULL as bus
> object when creating a bus message), with the most reduced feature set
> possible, and at the same time refuse to enqueue such messages on any
> bus, thus forcing people to use sd_bus_message_copy() to explicitly
> remarshal for the bus, instead of doing implicitly so.

Fully agree, that is also what I meant. (The reduced feature set would be
the functions I mentioned in the previous e-mail.)

> if you want to prep such a patch I think we should merge it.

OK, I will try. So we don't introduce any new message factory function
without bus parameter, but make use of existing `sd_bus_message_new`,
right? We will modify it to allow NULL bus ptr. However, this function
needs three things from the bus when initializing message:
`message_version`, `c

Re: [systemd-devel] Q: Wants and WantedBy links in generated units and circular dependencies

[Andrei Borzenkov]

On Thu, May 23, 2019 at 11:56 AM Ulrich Windl
 wrote:
>
> Hi!
>
> After seeing that systemd generators are run as the very first step in
> systemd's life (deduced from the timestamps), I quit the idea of using them,
> and started to use another sort of generator:
>
> I have a generator target, that creates another target and a few service
> targets.
> The interesting point is circular dependencies for the generated units, and
> I'd like to ask if the following would work:
>
> I need to enable a generated target to get ist wants-links installed; likewise
> the generated service units need to be enabled to get the wants link from the
> target to the service.
> As my generator created the service units first, then the target unit which
> "Wants" the service units.
> The idea is that starting the soingle target unit will start all depending
> service units.
>
> So far that is without enabling. I wonder whether I can enable the service
> units that are "WantedBy" the target unit _before_ the target unit was 
> actually
> generated.

If target unit Wants your service units, there is nothing to enable.

> If that doesn't work, I'll need a two-pass approach.
>
> For history, one of the odd things in systemd v228 is this:
>  # systemctl status iotwatch.target
> ● iotwatch.target
>Loaded: not-found (Reason: No such file or directory)
>Active: inactive (dead)
> # systemctl enable iotwatch.target   ### thios command must do something
> magic!

It also implicitly does "systemctl daemon-reload". It should not
really be necessary in this case (systemd should attempt to load
missing definition) but with so old version who knows.

> # systemctl status iotwatch.target
> ● iotwatch.target - iotwatch I/O performance monitor
>Loaded: loaded (/run/systemd/system/iotwatch.target; enabled; vendor
> preset: disabled)
>Active: inactive (dead)
>  Docs: man:iotwatch@.service(8)
>man:iotwatch-generator(8)
>
>
> So it seems I must enable units just to be able to query whether they are
> enabled...???
>

systemctl is-enabled
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Does "systemctl daemon-reload" discard service information?

[Andrei Borzenkov]

On Tue, May 21, 2019 at 10:50 AM Ulrich Windl
 wrote:
>
> >>> Andrei Borzenkov  schrieb am 20.05.2019 um 19:07 in
> Nachricht <4d103eef-d000-c9b2-9f7a-e0cda8ed6...@gmail.com>:
> > 20.05.2019 16:36, Ulrich Windl пишет:
> >> Hi!
> >>
> >> I have had the effect that a "systectl status" before and after a
> >> "daemon-reload" is different, while the service in question wasn't
> > restarted:
> >>
> > ...>
> >> Is that intentional?
> >>
> >
> > daemon-reload is known to lose state for years. Some problems get fixed,
> > new problems appear. Problems range from cosmetic to losing state of
> > units and jobs causing callers of systemd to "hang" waiting for job
> > completion. Unfortunately daemon-reload is often the only answer to
> > other reported problems (like in "systemd does not see fstab changes?
> > Run daemon-reload, where is the problem").
>
> So it's a bug?
>

Of course each specific bit of unit state which gets lost across
daemon-reload is a bug. Although in this case it is rather cosmetic,
as the main information is that unit is active which implies that all
necessary commands have been executed.

But more generally semantic of daemon-reload was never defined. What
should happen if active unit definition has changed in incompatible
way? Then run-time state no more matches unit definition and there is
no "right" information that can be shown.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: Re: Q: Wants and WantedBy links in generated units and circular dependencies

[Ulrich Windl]

>>> Andrei Borzenkov  schrieb am 23.05.2019 um 12:41 in
Nachricht
:
> On Thu, May 23, 2019 at 11:56 AM Ulrich Windl
>  wrote:
>>
>> Hi!
>>
>> After seeing that systemd generators are run as the very first step in
>> systemd's life (deduced from the timestamps), I quit the idea of using
them,
>> and started to use another sort of generator:
>>
>> I have a generator target, that creates another target and a few service
>> targets.
>> The interesting point is circular dependencies for the generated units,
and
>> I'd like to ask if the following would work:
>>
>> I need to enable a generated target to get ist wants-links installed; 
> likewise
>> the generated service units need to be enabled to get the wants link from 
> the
>> target to the service.
>> As my generator created the service units first, then the target unit
which
>> "Wants" the service units.
>> The idea is that starting the soingle target unit will start all depending
>> service units.
>>
>> So far that is without enabling. I wonder whether I can enable the service
>> units that are "WantedBy" the target unit _before_ the target unit was 
> actually
>> generated.
> 
> If target unit Wants your service units, there is nothing to enable.

I want to avoid the confusing "Reason: No such file or directory".

> 
>> If that doesn't work, I'll need a two-pass approach.
>>
>> For history, one of the odd things in systemd v228 is this:
>>  # systemctl status iotwatch.target
>> ● iotwatch.target
>>Loaded: not-found (Reason: No such file or directory)
>>Active: inactive (dead)
>> # systemctl enable iotwatch.target   ### thios command must do something
>> magic!
> 
> It also implicitly does "systemctl daemon-reload". It should not
> really be necessary in this case (systemd should attempt to load
> missing definition) but with so old version who knows.

The advantage of "enable" is that it outputs messages that show what it is
doing;.

> 
>> # systemctl status iotwatch.target
>> ● iotwatch.target - iotwatch I/O performance monitor
>>Loaded: loaded (/run/systemd/system/iotwatch.target; enabled; vendor
>> preset: disabled)
>>Active: inactive (dead)
>>  Docs: man:iotwatch@.service(8)
>>man:iotwatch-generator(8)
>>
>>
>> So it seems I must enable units just to be able to query whether they are
>> enabled...???
>>
> 
> systemctl is-enabled

Will "is-enabled" work where "status" fails with "Reason: No such file or
directory"?

Regards,
Ulrich

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Node.js sd-notify module visibility

[Mantas Mikulėnas]

On Thu, May 23, 2019 at 12:05 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Thu, May 23, 2019 at 09:25:02AM +0100, Rory Bradford wrote:
> > Hi,
> >
> > I actively maintain a Node.js module "sd-notify" available on GitHub
> > (https://github.com/roryrjb/sd-notify) and npm
> > (https://www.npmjs.com/package/sd-notify) that has been contributed to
> > and is being used by others. As the name suggests it binds to
> > sd_notify_* functions.
> >
> > It would be nice to be listed alongside other language bindings on this
> > page https://www.freedesktop.org/wiki/Software/systemd/ if possible,
> > especially as it is actively maintained.
> Links have been added.
>
> > Also I don't know if the projects listed in the GitHub organisation only
> > reflect those of official systemd contributors/developers but moving my
> > repo out into that namespace would be awesome and provide even more
> > community scrutiny.
> I sent you an invitation for a new @systemd/nodejs team. Once you accept
> that, you should be able to move your project under the systemd umbrella.
>

Hmm, now that it's under systemd/, maybe it should be renamed to
"node-sd-notify" or something similarly less-generic?

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Node.js sd-notify module visibility

[Rory Bradford]

Yeah of course, didn't even think. I'm happy with that but I've lost the
rights to change this.

On 23/05/2019 12:25, Mantas Mikulėnas wrote:
> On Thu, May 23, 2019 at 12:05 PM Zbigniew Jędrzejewski-Szmek
> mailto:zbys...@in.waw.pl>> wrote:
>
> On Thu, May 23, 2019 at 09:25:02AM +0100, Rory Bradford wrote:
> > Hi,
> >
> > I actively maintain a Node.js module "sd-notify" available on GitHub
> > (https://github.com/roryrjb/sd-notify) and npm
> > (https://www.npmjs.com/package/sd-notify) that has been
> contributed to
> > and is being used by others. As the name suggests it binds to
> > sd_notify_* functions.
> >
> > It would be nice to be listed alongside other language bindings
> on this
> > page https://www.freedesktop.org/wiki/Software/systemd/ if possible,
> > especially as it is actively maintained.
> Links have been added.
>
> > Also I don't know if the projects listed in the GitHub
> organisation only
> > reflect those of official systemd contributors/developers but
> moving my
> > repo out into that namespace would be awesome and provide even more
> > community scrutiny.
> I sent you an invitation for a new @systemd/nodejs team. Once you
> accept
> that, you should be able to move your project under the systemd
> umbrella.
>
>
> Hmm, now that it's under systemd/, maybe it should be renamed to
> "node-sd-notify" or something similarly less-generic?
>
> -- 
> Mantas Mikulėnas


pEpkey.asc
Description: application/pgp-keys
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Node.js sd-notify module visibility

[Zbigniew Jędrzejewski-Szmek]

On Thu, May 23, 2019 at 12:27:56PM +0100, Rory Bradford wrote:
> Yeah of course, didn't even think. I'm happy with that but I've lost the
> rights to change this.

Is "node-sd-notify" ok?

Zbyszek

> 
> On 23/05/2019 12:25, Mantas Mikulėnas wrote:
> > On Thu, May 23, 2019 at 12:05 PM Zbigniew Jędrzejewski-Szmek
> > mailto:zbys...@in.waw.pl>> wrote:
> >
> > On Thu, May 23, 2019 at 09:25:02AM +0100, Rory Bradford wrote:
> > > Hi,
> > >
> > > I actively maintain a Node.js module "sd-notify" available on GitHub
> > > (https://github.com/roryrjb/sd-notify) and npm
> > > (https://www.npmjs.com/package/sd-notify) that has been
> > contributed to
> > > and is being used by others. As the name suggests it binds to
> > > sd_notify_* functions.
> > >
> > > It would be nice to be listed alongside other language bindings
> > on this
> > > page https://www.freedesktop.org/wiki/Software/systemd/ if possible,
> > > especially as it is actively maintained.
> > Links have been added.
> >
> > > Also I don't know if the projects listed in the GitHub
> > organisation only
> > > reflect those of official systemd contributors/developers but
> > moving my
> > > repo out into that namespace would be awesome and provide even more
> > > community scrutiny.
> > I sent you an invitation for a new @systemd/nodejs team. Once you
> > accept
> > that, you should be able to move your project under the systemd
> > umbrella.
> >
> >
> > Hmm, now that it's under systemd/, maybe it should be renamed to
> > "node-sd-notify" or something similarly less-generic?
> >
> > -- 
> > Mantas Mikulėnas

> pub  3072R/1EC95E98 2019-04-21 Rory Bradford 
> 
> sub  3072R/5899FC77 2019-04-21 [expires: 2020-04-20]

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Node.js sd-notify module visibility

[Rory Bradford]

Yup, go for it.

On 23/05/2019 12:36, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, May 23, 2019 at 12:27:56PM +0100, Rory Bradford wrote:
>> Yeah of course, didn't even think. I'm happy with that but I've lost the
>> rights to change this.
> Is "node-sd-notify" ok?
>
> Zbyszek
>
>> On 23/05/2019 12:25, Mantas Mikulėnas wrote:
>>> On Thu, May 23, 2019 at 12:05 PM Zbigniew Jędrzejewski-Szmek
>>> mailto:zbys...@in.waw.pl>> wrote:
>>>
>>> On Thu, May 23, 2019 at 09:25:02AM +0100, Rory Bradford wrote:
>>> > Hi,
>>> >
>>> > I actively maintain a Node.js module "sd-notify" available on GitHub
>>> > (https://github.com/roryrjb/sd-notify) and npm
>>> > (https://www.npmjs.com/package/sd-notify) that has been
>>> contributed to
>>> > and is being used by others. As the name suggests it binds to
>>> > sd_notify_* functions.
>>> >
>>> > It would be nice to be listed alongside other language bindings
>>> on this
>>> > page https://www.freedesktop.org/wiki/Software/systemd/ if possible,
>>> > especially as it is actively maintained.
>>> Links have been added.
>>>
>>> > Also I don't know if the projects listed in the GitHub
>>> organisation only
>>> > reflect those of official systemd contributors/developers but
>>> moving my
>>> > repo out into that namespace would be awesome and provide even more
>>> > community scrutiny.
>>> I sent you an invitation for a new @systemd/nodejs team. Once you
>>> accept
>>> that, you should be able to move your project under the systemd
>>> umbrella.
>>>
>>>
>>> Hmm, now that it's under systemd/, maybe it should be renamed to
>>> "node-sd-notify" or something similarly less-generic?
>>>
>>> -- 
>>> Mantas Mikulėnas
>> pub  3072R/1EC95E98 2019-04-21 Rory Bradford 
>> 
>> sub  3072R/5899FC77 2019-04-21 [expires: 2020-04-20]


pEpkey.asc
Description: application/pgp-keys
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Node.js sd-notify module visibility

[Zbigniew Jędrzejewski-Szmek]

On Thu, May 23, 2019 at 12:43:27PM +0100, Rory Bradford wrote:
> Yup, go for it.

Done.

Zbyszek

> On 23/05/2019 12:36, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, May 23, 2019 at 12:27:56PM +0100, Rory Bradford wrote:
> >> Yeah of course, didn't even think. I'm happy with that but I've lost the
> >> rights to change this.
> > Is "node-sd-notify" ok?
> >
> > Zbyszek
> >
> >> On 23/05/2019 12:25, Mantas Mikulėnas wrote:
> >>> On Thu, May 23, 2019 at 12:05 PM Zbigniew Jędrzejewski-Szmek
> >>> mailto:zbys...@in.waw.pl>> wrote:
> >>>
> >>> On Thu, May 23, 2019 at 09:25:02AM +0100, Rory Bradford wrote:
> >>> > Hi,
> >>> >
> >>> > I actively maintain a Node.js module "sd-notify" available on GitHub
> >>> > (https://github.com/roryrjb/sd-notify) and npm
> >>> > (https://www.npmjs.com/package/sd-notify) that has been
> >>> contributed to
> >>> > and is being used by others. As the name suggests it binds to
> >>> > sd_notify_* functions.
> >>> >
> >>> > It would be nice to be listed alongside other language bindings
> >>> on this
> >>> > page https://www.freedesktop.org/wiki/Software/systemd/ if possible,
> >>> > especially as it is actively maintained.
> >>> Links have been added.
> >>>
> >>> > Also I don't know if the projects listed in the GitHub
> >>> organisation only
> >>> > reflect those of official systemd contributors/developers but
> >>> moving my
> >>> > repo out into that namespace would be awesome and provide even more
> >>> > community scrutiny.
> >>> I sent you an invitation for a new @systemd/nodejs team. Once you
> >>> accept
> >>> that, you should be able to move your project under the systemd
> >>> umbrella.
> >>>
> >>>
> >>> Hmm, now that it's under systemd/, maybe it should be renamed to
> >>> "node-sd-notify" or something similarly less-generic?
> >>>
> >>> -- 
> >>> Mantas Mikulėnas
> >> pub  3072R/1EC95E98 2019-04-21 Rory Bradford 
> >> 
> >> sub  3072R/5899FC77 2019-04-21 [expires: 2020-04-20]

> pub  3072R/1EC95E98 2019-04-21 Rory Bradford 
> 
> sub  3072R/5899FC77 2019-04-21 [expires: 2020-04-20]

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] chkconfig on preferred to --add?

[Roger Pack]

As a note, if I have a sysV  /etc/init.d/name service that is "turned
on" by "chkconfig --add name" it seems that it adds it to *different
targets* than what "systemctl enable name" does (which appears to run
"chkconfig name on" enabling it for all runlevels).  This seems a bit
confusing?  is it expected?  Or perhaps my systemd version is just
old?

$ chkconfig --add service-name
$ chkconfig --list service-name
service-name 0:off 1:off 2:off 3:on 4:on 5:on 6:off
$ systemctl disable service-name
service-name is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig service-name off
$ systemctl enable service-name
service-name is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig service-name on
$ chkconfig --list service-name
service-name 0:off 1:off 2:on 3:on 4:on 5:on 6:off -> 2 is different

$ systemctl --version
systemd 219

Thanks!
-Roger-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] coredump missing in systemd

[Dorian ROSSE]

Hello everybody,


I went to follow this link : https://wiki.archlinux.org/index.php/Core_dump

I readen also coredump is missing for systemd,

How to install core dump ?

Because I can’t use gdb for dbus-daemon as Following :

(gdb) generate-core-file
You can't do that without a process to debug.

pgrep -f dbus-daemon
31873
root@bitfenix-server:/etc/systemd# gdb -p 31873
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 31873
ptrace: No such process.
(gdb) generate-core-file 31873
You can't do that without a process to debug.

Thank you in advance to help me which coredump,

Regards.


Dorian ROSSE.
Provenance : Courrier pour 
Windows 10

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] chkconfig on preferred to --add?

[Reindl Harald]

Am 23.05.19 um 18:29 schrieb Roger Pack:
> As a note, if I have a sysV  /etc/init.d/name service that is "turned
> on" by "chkconfig --add name" it seems that it adds it to *different
> targets* than what "systemctl enable name" does (which appears to run
> "chkconfig name on" enabling it for all runlevels).  This seems a bit
> confusing?  is it expected?  Or perhaps my systemd version is just
> old?

chkconfig has nothing to do with systemd and is a distro-wrapper you had
7 years time to get rid of
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] chkconfig on preferred to --add?

[Lennart Poettering]

On Do, 23.05.19 10:29, Roger Pack (rogerdpa...@gmail.com) wrote:

> As a note, if I have a sysV  /etc/init.d/name service that is "turned
> on" by "chkconfig --add name" it seems that it adds it to *different
> targets* than what "systemctl enable name" does (which appears to run
> "chkconfig name on" enabling it for all runlevels).  This seems a bit
> confusing?  is it expected?  Or perhaps my systemd version is just
> old?

It's probably a question to ask the chkconfig community, I am not sure
what the difference is, and the man page is not particularly
enlightening.

Note that systemd is not invoking chkconfig directly but instead
/usr/lib/systemd/systemd-sysv-install which is supposed to do the
right thing, and it's up to the distros to make that a shell script or
so that does the right thing. hence it's entirely within the domain of
the distro/chkconfig to do the right thing, we don't control that from
systemd's side.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] coredump missing in systemd

[Ryan Gonzalez]

coredumpctl debug dbus-daemon

assuming it already crashed. M

-- Ryan
https://refi64.com/
On May 23, 2019, 12:16 PM -0500, Dorian ROSSE , wrote:
> Hello everybody,
>
>
> I went to follow this link : https://wiki.archlinux.org/index.php/Core_dump
>
> I readen also coredump is missing for systemd,
>
> How to install core dump ?
>
> Because I can’t use gdb for dbus-daemon as Following :
>
> (gdb) generate-core-file
> You can't do that without a process to debug.
>
> pgrep -f dbus-daemon
> 31873
> root@bitfenix-server:/etc/systemd# gdb -p 31873
> GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
> Copyright (C) 2018 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> Attaching to process 31873
> ptrace: No such process.
> (gdb) generate-core-file 31873
> You can't do that without a process to debug.
>
> Thank you in advance to help me which coredump,
>
> Regards.
>
>
> Dorian ROSSE.
> Provenance : Courrier pour Windows 10
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] In unit files of systemd version 234 Type=notify not working

[Rajshekhar Sanda]

Hi all,


We are building Genivi 14 in which we are trying to launch weston at boot time 
with service file.


service file is as follows:



[Unit]
Description= launch weston
Requires=  dbus-session.service dbus.service systemd-user-sessions.service
After= dbus-session.socket dbus.service  dbus-session.service 
systemd-user-sessions.service  session-c1.scope
ConditionPathExists=/dev/tty0

[Service]
Type=notify
User=root
Restart=on-failure
ExecStart=/usr/bin/weston
NotifyAccess=all
PAMName=login
StandardInput=tty-fail
TTYPath=/dev/tty7
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=yes
UtmpIdentifier=tty7
UtmpMode=root
TimeoutStartSec=60
WatchdogSec=20
#ExecStart=/usr/bin/weston

[Install]
WantedBy=basic.target

---


Here Type=notify is not supporting.

I observed other types are working fine.

Please help me to solve this issue.

Thank You

Regards,
Rajshekhar Sanda
Tata Consultancy Services Limited
Mailto: rajshekhar.sa...@tcs.com
Website: http://www.tcs.com

Experience certainty.IT Services
   Business Solutions
   Consulting






=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel