[systemd-devel] how to correctly specify dependency on dbus

[prashantkumar dhotre]

Hi
For my service,  I have:

# cat my.service
[Unit]
Description=My Service
After=dbus.service
Requires=dbus.service
...
...

Some time i see that my service fails to get dbus connection
(dbus_bus_get_private() fails without any error msg).
one possibility i think is that dbus is not fully initialized.
From above service file config, i understand when i start my service,
dbus service is started 1st and then my service.
but i am not sure if my service start step is delayed until dbus is
fully up , initialized and running and ready to accept conections.
is there a way to specify this in my service file.

For ex, for systemd-networkd,service, i see it specify  like :

# On kdbus systems we pull in the busname explicitly, because it
# carries policy that allows the daemon to acquire its name.
Wants=org.freedesktop.network1.busname
After=org.freedesktop.network1.busname


Can i use same (specifying After/Wants on a dbus name) ?
Appreciate your help on this.
Thanks
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Härdeman]

On Tue, Apr 25, 2017 at 09:47:24AM -0500, Dan Williams wrote:
>On Tue, 2017-04-25 at 07:45 +, David Härdeman wrote:
>> April 24, 2017 5:49 PM, "Dan Williams"  wrote:
>>> 
>>> It's not clear that the GNOME side was implemented correctly yet.
>>> Would be nice to see the sample code.
>>> 
>>> Dan
>> 
>> My GNOME-based client was based on the gdbus-example-objectmanager-
>> client.c so I hope it's correct, but sure, I'll try to pare down the
>> GNOME/gdbus-based client code and the (sd-bus based) server code to
>> two simple test cases and provide those later this week.
>
>Cool.  I'd be happy to take a look at it.  It may well turn out to be a
>gdbus bug, but without seeing the code it's not clear.

I've added test cases at:
https://github.com/Alphix/gdbus-sdbus-test

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

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Härdeman]

On Tue, Apr 25, 2017 at 09:21:19PM +0200, David Härdeman wrote:
>On Tue, Apr 25, 2017 at 09:54:45AM +0200, David Herrmann wrote:
>>No, it does not. sd-bus was inconsistent. See, there are 3 things
>>involved in the Object-Manager:
>>
>>Signal: InterfacesAdded
>>Signal: InterfacesRemoved
>>Call: GetManagedObjects
>>
>>The first two signals are used to add and remove objects (and their
>>respective interfaces) at runtime. The GetManagedObjects() call is
>>used to bootstrap, that is, to get the initial set of objects (and
>>their respective interfaces) when starting your application.
>>
>>So far, sd-bus reported the builtin interfaces correctly via the
>>signals, but did not return that information in the
>>GetManagedObjects() call. My patch fixed this omission.
>>The effect of this is that objects added/removed at runtime work fine,
>>but if an object was there already when your application starts, then
>>it will never be removed, since gdbus will see an interface-count
>>mismatch (as you observed above).
>>
>>Hence, the patch I provided fixes how sd-bus provides this
>>information. It does *not* change any policy.
>>
>>I think the 2 underlying problems you saw are bugs in both gdbus and
>>sd-bus. The one in sd-bus I tried to fix above, the one in gdbus is
>>only about counting interfaces and properly detecting negative
>>interface-counts. The gdbus bug is non-severe, though, since it
>>originates in a buggy remote client. So there is no hard reason to
>>change gdbus there.
>
>Ok, I've tried the patch. It seems to fix things insofar that
>InterfacesAdded/InterfacesRemoved/GetManagedObjects all report 5
>interfaces (checked with dbus-monitor).
>
>gdbus still gets royally confused though. It seems to report 5
>interfaces for objects which are added dynamically (i.e. signalled via
>InterfacesAdded) and 1 interface for objects which are generated via
>GetManagedObjects (even though the sd-bus server reports 5 interfaces).

Scratch that. With your patch gdbus seems to consistently report 5
interfaces. But there's still some confusion to address in gdbus (the
additional interfaces have no names for example).

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

Re: [systemd-devel] monitoring systemd unit flapping

[Jeremy Eder]

Sorry, I did not explain myself clearly.  systemd is doing nothing wrong.
What I'd like to do is find an optimal way to notify our monitoring system
(zabbix) that a service is flapping.  We can probably script something.
Just looking to see if there's a more elegant way.  Looking also at
OnFailure

https://serverfault.com/questions/694818/get-notification-when-systemd-monitored-service-enters-failed-state

At the same time, trying to avoid false positives in the monitoring system,
so one failure is OK but when it hits startburstlimit, things are bad, even
if the service doesn't immediately crash.  That's the thing; it might take
a few seconds/minutes to fail.  I realize this could be considered an edge
case...perhaps an equivalent of OnFailure could be OnStartBurstLimit= ?

On Tue, Apr 25, 2017 at 1:35 PM, Reindl Harald 
wrote:

>
>
> Am 25.04.2017 um 17:30 schrieb Jeremy Eder:
>
>> If we have a service that is flapping because it's crashing after
>> startup...what's the right way to monitor for that condition?  Eventually
>> it triggers startburstlimit, was thinking that if we hit startburstlimit
>> that the service could set some special bit that we could look for.
>>
>> Like ... systemctl is-flapping myservice --quiet
>>
>> Any other possibilities?
>>
>
> just put "RestartSec=1" in the unit-file
>
> the default is ridiculous low and easily triggers the restart-limit
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>



-- 

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

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Härdeman]

On Tue, Apr 25, 2017 at 09:54:45AM +0200, David Herrmann wrote:
>On Tue, Apr 25, 2017 at 9:40 AM, David Härdeman  wrote:
>> April 21, 2017 1:22 PM, "David Herrmann"  wrote:
>>> This change makes sure all objects have the built-in interfaces
>>> reported at all times. The GetManagedObjects() call didn't report them
>>> so far.
>>
>> Quite the contrary? If you look at the output from dbus-monitor above, 
>> you'll see that it is sd-bus that already *does* report all interfaces while 
>> gdbus doesnt?
>
>No, it does not. sd-bus was inconsistent. See, there are 3 things
>involved in the Object-Manager:
>
>Signal: InterfacesAdded
>Signal: InterfacesRemoved
>Call: GetManagedObjects
>
>The first two signals are used to add and remove objects (and their
>respective interfaces) at runtime. The GetManagedObjects() call is
>used to bootstrap, that is, to get the initial set of objects (and
>their respective interfaces) when starting your application.
>
>So far, sd-bus reported the builtin interfaces correctly via the
>signals, but did not return that information in the
>GetManagedObjects() call. My patch fixed this omission.
>The effect of this is that objects added/removed at runtime work fine,
>but if an object was there already when your application starts, then
>it will never be removed, since gdbus will see an interface-count
>mismatch (as you observed above).
>
>Hence, the patch I provided fixes how sd-bus provides this
>information. It does *not* change any policy.
>
>I think the 2 underlying problems you saw are bugs in both gdbus and
>sd-bus. The one in sd-bus I tried to fix above, the one in gdbus is
>only about counting interfaces and properly detecting negative
>interface-counts. The gdbus bug is non-severe, though, since it
>originates in a buggy remote client. So there is no hard reason to
>change gdbus there.

Ok, I've tried the patch. It seems to fix things insofar that
InterfacesAdded/InterfacesRemoved/GetManagedObjects all report 5
interfaces (checked with dbus-monitor).

gdbus still gets royally confused though. It seems to report 5
interfaces for objects which are added dynamically (i.e. signalled via
InterfacesAdded) and 1 interface for objects which are generated via
GetManagedObjects (even though the sd-bus server reports 5 interfaces).

I'll start working on a testcase...

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

[systemd-devel] Plan for DHCP Option 119?

[Daniel Wang]

Hi all,

First of all this is my first email to this list so apologies if it's not
worded perfectly.

I am wondering if there's any plan to support Domain Search List option in
networkd. Some cloud providers like GCE, advertise multiple search domains
through option 119 and they just get ignored in today's networkd.

The bug https://github.com/systemd/systemd/issues/2710 doesn't seem to get
any attention. What's the complexities behind it? Does anyone on this list
have any reference implementation?

-- 
Best,
Daniel


smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] monitoring systemd unit flapping

[Reindl Harald]

Am 25.04.2017 um 17:30 schrieb Jeremy Eder:
If we have a service that is flapping because it's crashing after 
startup...what's the right way to monitor for that condition?  
Eventually it triggers startburstlimit, was thinking that if we hit 
startburstlimit that the service could set some special bit that we 
could look for.


Like ... systemctl is-flapping myservice --quiet

Any other possibilities?


just put "RestartSec=1" in the unit-file

the default is ridiculous low and easily triggers the restart-limit
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] fully volatile running from ram

[jr]

hello,

in a fully-volatile boot scenario /usr from a physical disk gets mounted on
top of an instance of a tmpfs. my first question is why is that necessary?
(the tmpfs part i mean)

my second question is, would it be possible to do the same but rather than
mounting the /usr *populate* the said tmpfs with OS tree from said physical
disk, preferably in a blocked or fs cached setup (db-cache or bcachefs). i
realise that this can be done easily in initrd or even initramfs can hold
the /usr but the problem there is when we boot "developmen" and not
"production" in which case we want updates to be written to disk.

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

[systemd-devel] monitoring systemd unit flapping

[Jeremy Eder]

If we have a service that is flapping because it's crashing after
startup...what's the right way to monitor for that condition?  Eventually
it triggers startburstlimit, was thinking that if we hit startburstlimit
that the service could set some special bit that we could look for.

Like ... systemctl is-flapping myservice --quiet

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

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[Dan Williams]

On Tue, 2017-04-25 at 07:45 +, David Härdeman wrote:
> April 24, 2017 5:49 PM, "Dan Williams"  wrote:
> > On Mon, 2017-04-24 at 16:50 +0200, Lennart Poettering wrote:
> > > On Fri, 21.04.17 13:22, David Herrmann (dh.herrm...@gmail.com)
> > > wrote:
> > > 
> > > > > > Anyway, gdbus bugs aside, it seems that the interfaces
> > > > > > reported by
> > > > > > sd-bus should match what gdbus does? (assuming, of course,
> > > > > > that gdbus
> > > > > > can be considered the "reference" implementation).
> > > > > 
> > > > > Does the appended patch fix your issue?
> > > > > (line-breaks might be screwed, sorry)
> > > > 
> > > > Haven't tried it yet, but just from reading the patch...it
> > > > seems
> > > > to do
> > > > the opposite of what I'd expect? I.e. add *more* interfaces?
> > > 
> > > This change makes sure all objects have the built-in interfaces
> > > reported at all times. The GetManagedObjects() call didn't report
> > > them
> > > so far.
> > > 
> > > Note that we really better report all interfaces an object
> > > supports. I
> > > don't know why glib does not do this, but I think it should.
> > > 
> > > Yeah, I#d agree with that. I think we should provide complete
> > > information, and that means including built-in interfaces in all
> > > our
> > > messages, in particular as some of them are optional. It appears
> > > to
> > > me, that gdbus should be changed here, not sd-bus...
> > 
> > It's not clear that the GNOME side was implemented correctly yet.
> > Would be nice to see the sample code.
> > 
> > Dan
> 
> My GNOME-based client was based on the gdbus-example-objectmanager-
> client.c so I hope it's correct, but sure, I'll try to pare down the
> GNOME/gdbus-based client code and the (sd-bus based) server code to
> two simple test cases and provide those later this week.

Cool.  I'd be happy to take a look at it.  It may well turn out to be a
gdbus bug, but without seeing the code it's not clear.

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

Re: [systemd-devel] Activation socket overwritten while socket service running

[Lennart Poettering]

On Tue, 25.04.17 10:17, Trent Lloyd (tr...@lloyd.id.au) wrote:

> I had two general thoughts,
> 
> (a) Can I make a unit change to "improve" the situation, for example adding
> PartOf=avahi-daemon.service to avahi-daemon.socket.  I have noticed that
> CUPS and Docker (err, moby) seem to ship this though most other things
> don't; however that does seem to take away the ability to actually use
> socket activation since they'll always activate together making it mostly
> pointless (even though in most cases with avahi specifically, we want to
> actually startup and not wait to be activated so the network side is
> active).  So this seems non-ideal and I think probably this doesn't make
> sense.  It does make me wonder if others had the same thought-process and/or
> problems though.

I figure a BindsTo=avahi-daemon.socket in avahi-daemon.service
wouldn't be too bad. That way if the service is stopped the socket is
stopped too.

> (b) Would it make sense to improve systemd to monitor the socket status and
> alert or "exit" the service (making it eligible to be restarted,
> particularly it would be restarted automatically when avahi-daemon.service
> is again started) if it is no longer actually bound to the on disk path.  Or
> otherwise improve the situation directly from the systemd side in some way,
> such as checking the socket status at least when the service is restarting.
> Restarting avahi-daemon.socket does in fact restart avahi-daemon.service (if
> nothing else by way of necessity I guess, since a new FD has to be passed
> in) but the reverse is not true by default (which does make sense for
> short-lived activated services, you don't want to re-bind the socket every
> time and leaves a race time the service is unavailable)

I figure it would be OK for PID 1 to use inotify to watch for the
socket node to be removed/replaced in the file system, and if that
happens we could place the socket unit in a failure state or so.

Would be happy to take a patch for that!

> From my view the "real problem" is that the issue is entirely invisible.
> The socket does not work, there are no errors visible on either the socket
> or service and restarting avahi-daemon.service does not fix it.  Restarting
> avahi-daemon.socket does fix it and I appreciate that, but I think that is
> confusing in many cases.  I am feeling that having the socket service exit
> if the path becomes invalid may be a sensible improvement but I thought I'd
> float the idea before working on it.

Yeah, it is indeed to easy to debug issues like that. I'd be open to
making this more discoverable, by for example refusing to start a
service whose sockets have disappeared in the file system (or maybe
warn but permit), but I am not aware of any nice way how we could
detect that the fs node still maps to the same socket we originally
created. To my knowledge there is no Linux/UNIX API for something like
that...

Lennart

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

Re: [systemd-devel] hibernation sometimes not working

[Michał Zegan]

I have probably discovered the cause, and it is, that the memory image
would be too large to fit in the swap space, and I would have to
increase the swap space.

W dniu 25.04.2017 o 05:34, Andrei Borzenkov pisze:
> 25.04.2017 04:45, Michał Zegan пишет:
>> Hello.
>>
>> I have archlinux with systemd (currently the newest released).
>> Hibernation works properly in this computer. however, after few
>> hibernations (or maybe something else triggers this condition?) it
>> suddenly stops working. trying to do systemctl hibernate in the terminal
>> says something like unknown sleep verb (I do not currently have the
>> exact message, but it is saying about unknown sleep verb). I haven't
>> found a way to hibernate when this is triggered, and I usually fully
>> shutdown the computer then.
>> Any ideas?
>>
> 
> I do not see "unknown sleep verb" message in sources; there is "Sleep
> verb not supported" which means, your current kernel says it cannot do
> what you asked. Please show exact message you get.
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd --session instance?

[Simon McVittie]

On Tue, 25 Apr 2017 at 09:55:16 +0200, Lennart Poettering wrote:
> If you now
> introduce a third set of search paths /usr/lib/systemd/session, then
> you'll open an entirely new can of worms, as no apps install their
> unit files there, and you'd have to convince every single one of them
> to do so now too, and understand the complexity this involves, and the
> thin, vague difference between being called from --user and --system.
> 
> So, sorry, but this would have massive implications on the entire app
> ecosystem, and I am very sure this isn't worth it. Sorry!

This is essentially the same argument as the reason why
`dbus-daemon --session` can be configured (by a distro or sysadmin) to
be one per login session, or one per `systemd --user`, but never both at
the same time. Having both exist at the same time (a "user bus" *and* a
per-login-session bus) would just be too confusing, and everyone would
use the wrong one.

If a particular service does want to exist once per login session or
once per X11 display, instanced services (`xwallpaper@:0.service`)
are one possible solution.

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

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Herrmann]

Hey

On Tue, Apr 25, 2017 at 10:05 AM, Lennart Poettering
 wrote:
> On Tue, 25.04.17 09:54, David Herrmann (dh.herrm...@gmail.com) wrote:
>
>> >> This change makes sure all objects have the built-in interfaces
>> >> reported at all times. The GetManagedObjects() call didn't report them
>> >> so far.
>> >
>> > Quite the contrary? If you look at the output from dbus-monitor above, 
>> > you'll see that it is sd-bus that already *does* report all interfaces 
>> > while gdbus doesnt?
>>
>> No, it does not. sd-bus was inconsistent. See, there are 3 things
>> involved in the Object-Manager:
>>
>> Signal: InterfacesAdded
>> Signal: InterfacesRemoved
>> Call: GetManagedObjects
>>
>> The first two signals are used to add and remove objects (and their
>> respective interfaces) at runtime. The GetManagedObjects() call is
>> used to bootstrap, that is, to get the initial set of objects (and
>> their respective interfaces) when starting your application.
>>
>> So far, sd-bus reported the builtin interfaces correctly via the
>> signals, but did not return that information in the
>> GetManagedObjects() call. My patch fixed this omission.
>> The effect of this is that objects added/removed at runtime work fine,
>> but if an object was there already when your application starts, then
>> it will never be removed, since gdbus will see an interface-count
>> mismatch (as you observed above).
>>
>> Hence, the patch I provided fixes how sd-bus provides this
>> information. It does *not* change any policy.
>>
>> I think the 2 underlying problems you saw are bugs in both gdbus and
>> sd-bus. The one in sd-bus I tried to fix above, the one in gdbus is
>> only about counting interfaces and properly detecting negative
>> interface-counts. The gdbus bug is non-severe, though, since it
>> originates in a buggy remote client. So there is no hard reason to
>> change gdbus there.
>
> Could you please send the sd-bus side fix as PR?

Now pending as #5799.

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

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[Lennart Poettering]

On Tue, 25.04.17 09:54, David Herrmann (dh.herrm...@gmail.com) wrote:

> >> This change makes sure all objects have the built-in interfaces
> >> reported at all times. The GetManagedObjects() call didn't report them
> >> so far.
> >
> > Quite the contrary? If you look at the output from dbus-monitor above, 
> > you'll see that it is sd-bus that already *does* report all interfaces 
> > while gdbus doesnt?
> 
> No, it does not. sd-bus was inconsistent. See, there are 3 things
> involved in the Object-Manager:
> 
> Signal: InterfacesAdded
> Signal: InterfacesRemoved
> Call: GetManagedObjects
> 
> The first two signals are used to add and remove objects (and their
> respective interfaces) at runtime. The GetManagedObjects() call is
> used to bootstrap, that is, to get the initial set of objects (and
> their respective interfaces) when starting your application.
> 
> So far, sd-bus reported the builtin interfaces correctly via the
> signals, but did not return that information in the
> GetManagedObjects() call. My patch fixed this omission.
> The effect of this is that objects added/removed at runtime work fine,
> but if an object was there already when your application starts, then
> it will never be removed, since gdbus will see an interface-count
> mismatch (as you observed above).
> 
> Hence, the patch I provided fixes how sd-bus provides this
> information. It does *not* change any policy.
> 
> I think the 2 underlying problems you saw are bugs in both gdbus and
> sd-bus. The one in sd-bus I tried to fix above, the one in gdbus is
> only about counting interfaces and properly detecting negative
> interface-counts. The gdbus bug is non-severe, though, since it
> originates in a buggy remote client. So there is no hard reason to
> change gdbus there.

Could you please send the sd-bus side fix as PR?

Lennart

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

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Härdeman]

April 25, 2017 9:54 AM, "David Herrmann"  wrote:

> Hi
> 
> On Tue, Apr 25, 2017 at 9:40 AM, David Härdeman  wrote:
> 
>> April 21, 2017 1:22 PM, "David Herrmann"  wrote:
>>> On Fri, Apr 21, 2017 at 11:50 AM, David Härdeman  wrote:
>> 
>> On Thu, Apr 20, 2017 at 02:19:22PM +0200, David Herrmann wrote:
>> On Thu, Apr 20, 2017 at 12:06 PM, David Härdeman  wrote:
>> I'm implementing a server which creates an ObjectManager using the
>> sd-bus API and there seems to be some differences between how gdbus and
>> sd-bus implements the API.
>> 
>> I implemented a simple ObjectManager at /org/gnome/TestManager which
>> exports objects /org/gnome/TestManager/fooX with interface
>> org.gnome.TestManager.Device.
>> 
>> Under sd-bus, if an object is removed, the following signal is
>> generated:
>> 
>> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
>> serial=90 path=/org/gnome/TestManager;
>> interface=org.freedesktop.DBus.ObjectManager;
>> member=InterfacesRemoved
>> object path "/org/gnome/TestManager/foo0"
>> array [
>> string "org.freedesktop.DBus.Peer"
>> string "org.freedesktop.DBus.Introspectable"
>> string "org.freedesktop.DBus.Properties"
>> string "org.freedesktop.DBus.ObjectManager"
>> string "org.gnome.TestManager.Device"
>> ]
>> 
>> If I implement the same simple server in gdbus, the signal is instead:
>> 
>> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
>> serial=90 path=/org/gnome/TestManager;
>> interface=org.freedesktop.DBus.ObjectManager;
>> member=InterfacesRemoved
>> object path "/org/gnome/TestManager/foo0"
>> array [
>> string "org.gnome.TestManager.Device"
>> ]
>> 
>> The corresponding signals are also generated when an object is added.
>> 
>> Does the appended patch fix your issue?
>> (line-breaks might be screwed, sorry)
>> 
>> Haven't tried it yet, but just from reading the patch...it seems to do
>> the opposite of what I'd expect? I.e. add *more* interfaces?
>>> This change makes sure all objects have the built-in interfaces
>>> reported at all times. The GetManagedObjects() call didn't report them
>>> so far.
>> 
>> Quite the contrary? If you look at the output from dbus-monitor above, 
>> you'll see that it is sd-bus
>> that already *does* report all interfaces while gdbus doesnt?
> 
> No, it does not. sd-bus was inconsistent. See, there are 3 things
> involved in the Object-Manager:
> 
> Signal: InterfacesAdded
> Signal: InterfacesRemoved
> Call: GetManagedObjects
> 
> The first two signals are used to add and remove objects (and their
> respective interfaces) at runtime. The GetManagedObjects() call is
> used to bootstrap, that is, to get the initial set of objects (and
> their respective interfaces) when starting your application.
> 
> So far, sd-bus reported the builtin interfaces correctly via the
> signals, but did not return that information in the
> GetManagedObjects() call. My patch fixed this omission.
> The effect of this is that objects added/removed at runtime work fine,
> but if an object was there already when your application starts, then
> it will never be removed, since gdbus will see an interface-count
> mismatch (as you observed above).
> 
> Hence, the patch I provided fixes how sd-bus provides this
> information. It does *not* change any policy.

Oh, I see. Thanks. I'll try the patch ASAP.

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

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Herrmann]

Hi

On Tue, Apr 25, 2017 at 9:40 AM, David Härdeman  wrote:
> April 21, 2017 1:22 PM, "David Herrmann"  wrote:
>> On Fri, Apr 21, 2017 at 11:50 AM, David Härdeman  wrote:
>>> On Thu, Apr 20, 2017 at 02:19:22PM +0200, David Herrmann wrote:
 On Thu, Apr 20, 2017 at 12:06 PM, David Härdeman  wrote:
>>> I'm implementing a server which creates an ObjectManager using the
>>> sd-bus API and there seems to be some differences between how gdbus and
>>> sd-bus implements the API.
>>>
>>> I implemented a simple ObjectManager at /org/gnome/TestManager which
>>> exports objects /org/gnome/TestManager/fooX with interface
>>> org.gnome.TestManager.Device.
>>>
>>> Under sd-bus, if an object is removed, the following signal is
>>> generated:
>>>
>>> signal time=1492642227.714223 sender=:1.104 -> destination=(null 
>>> destination)
>>> serial=90 path=/org/gnome/TestManager;
>>> interface=org.freedesktop.DBus.ObjectManager;
>>> member=InterfacesRemoved
>>> object path "/org/gnome/TestManager/foo0"
>>> array [
>>> string "org.freedesktop.DBus.Peer"
>>> string "org.freedesktop.DBus.Introspectable"
>>> string "org.freedesktop.DBus.Properties"
>>> string "org.freedesktop.DBus.ObjectManager"
>>> string "org.gnome.TestManager.Device"
>>> ]
>>>
>>> If I implement the same simple server in gdbus, the signal is instead:
>>>
>>> signal time=1492642227.714223 sender=:1.104 -> destination=(null 
>>> destination)
>>> serial=90 path=/org/gnome/TestManager;
>>> interface=org.freedesktop.DBus.ObjectManager;
>>> member=InterfacesRemoved
>>> object path "/org/gnome/TestManager/foo0"
>>> array [
>>> string "org.gnome.TestManager.Device"
>>> ]
>>>
>>> The corresponding signals are also generated when an object is added.
> 
 Does the appended patch fix your issue?
 (line-breaks might be screwed, sorry)
>>>
>>> Haven't tried it yet, but just from reading the patch...it seems to do
>>> the opposite of what I'd expect? I.e. add *more* interfaces?
>>
>> This change makes sure all objects have the built-in interfaces
>> reported at all times. The GetManagedObjects() call didn't report them
>> so far.
>
> Quite the contrary? If you look at the output from dbus-monitor above, you'll 
> see that it is sd-bus that already *does* report all interfaces while gdbus 
> doesnt?

No, it does not. sd-bus was inconsistent. See, there are 3 things
involved in the Object-Manager:

Signal: InterfacesAdded
Signal: InterfacesRemoved
Call: GetManagedObjects

The first two signals are used to add and remove objects (and their
respective interfaces) at runtime. The GetManagedObjects() call is
used to bootstrap, that is, to get the initial set of objects (and
their respective interfaces) when starting your application.

So far, sd-bus reported the builtin interfaces correctly via the
signals, but did not return that information in the
GetManagedObjects() call. My patch fixed this omission.
The effect of this is that objects added/removed at runtime work fine,
but if an object was there already when your application starts, then
it will never be removed, since gdbus will see an interface-count
mismatch (as you observed above).

Hence, the patch I provided fixes how sd-bus provides this
information. It does *not* change any policy.

I think the 2 underlying problems you saw are bugs in both gdbus and
sd-bus. The one in sd-bus I tried to fix above, the one in gdbus is
only about counting interfaces and properly detecting negative
interface-counts. The gdbus bug is non-severe, though, since it
originates in a buggy remote client. So there is no hard reason to
change gdbus there.

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

Re: [systemd-devel] Systemd --session instance?

[Lennart Poettering]

On Mon, 24.04.17 20:09, Benno Fünfstück (benno.fuenfstu...@gmail.com) wrote:

> Thank you Lennart for taking the time to answer my question. It does make
> sense that you wouldn't want to support multiple sessions in big desktop
> environments like Gnome or KDE or any complex software.
> 
> However, it seems to me that there would be quite some usecases that fall
> outside these where multiple sessions make sense:
> 
> * first, while most software may not support multiple *graphical* sessions,
> it would be nice to be able to isolate my non-graphical sessions (like tty
> or ssh or whatever) from the, perhaps single, graphical session. As it
> stands, if I want to use systemd for managing graphical daemons, I have to
> import things like DISPLAY into the systemd --user instance which feels
> wrong to me, as there may be many other user services that do not rely on
> that variable at all and should not care.

Multiple per-user text sessions should be supported just fine. All we
changed is that we now put the focus on a single graphical session per
user at a time.

> * second, you say that big, complex software does not support multiple
> sessions sanely. However, I feel like this is a feature that would be most
> used by people running very lightweight graphical sessions. For example, I
> currently start my graphical services in `.xinitrc`. It would be very nice
> to be able to use systemd for this, as that would allow me to sanely stop
> all daemons at logout time.
> 
> I understand that for most users this feature may not be strictly
> necessary. There is a cost associated with maintaining this in systemd. But
> couldn't most of the code be shared with systemd user support? Or are there
> any other costs that I'm overlooking, apart from the increased complexity &
> maintenance cost to the systemd codebase?

Well, the difference between "systemd --user" and "systemd --system"
is dominantly one of search paths: where to look for unit files and
other resources: /usr/lib/systemd/system vs. /usr/lib/systemd/user and so on. 
If you now
introduce a third set of search paths /usr/lib/systemd/session, then
you'll open an entirely new can of worms, as no apps install their
unit files there, and you'd have to convince every single one of them
to do so now too, and understand the complexity this involves, and the
thin, vague difference between being called from --user and --system.

So, sorry, but this would have massive implications on the entire app
ecosystem, and I am very sure this isn't worth it. Sorry!

Lennart

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

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Härdeman]

April 24, 2017 5:49 PM, "Dan Williams"  wrote:
> On Mon, 2017-04-24 at 16:50 +0200, Lennart Poettering wrote:
>> On Fri, 21.04.17 13:22, David Herrmann (dh.herrm...@gmail.com) wrote:
>> 
> Anyway, gdbus bugs aside, it seems that the interfaces
> reported by
> sd-bus should match what gdbus does? (assuming, of course,
> that gdbus
> can be considered the "reference" implementation).
 
 Does the appended patch fix your issue?
 (line-breaks might be screwed, sorry)
>>> 
>>> Haven't tried it yet, but just from reading the patch...it seems
>>> to do
>>> the opposite of what I'd expect? I.e. add *more* interfaces?
>> 
>> This change makes sure all objects have the built-in interfaces
>> reported at all times. The GetManagedObjects() call didn't report
>> them
>> so far.
>> 
>> Note that we really better report all interfaces an object
>> supports. I
>> don't know why glib does not do this, but I think it should.
>> 
>> Yeah, I#d agree with that. I think we should provide complete
>> information, and that means including built-in interfaces in all our
>> messages, in particular as some of them are optional. It appears to
>> me, that gdbus should be changed here, not sd-bus...
> 
> It's not clear that the GNOME side was implemented correctly yet.
> Would be nice to see the sample code.
> 
> Dan

My GNOME-based client was based on the gdbus-example-objectmanager-client.c so 
I hope it's correct, but sure, I'll try to pare down the GNOME/gdbus-based 
client code and the (sd-bus based) server code to two simple test cases and 
provide those later this week.

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

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Härdeman]

April 21, 2017 1:22 PM, "David Herrmann"  wrote:
> On Fri, Apr 21, 2017 at 11:50 AM, David Härdeman  wrote:
>> On Thu, Apr 20, 2017 at 02:19:22PM +0200, David Herrmann wrote:
>>> On Thu, Apr 20, 2017 at 12:06 PM, David Härdeman  wrote:
>> I'm implementing a server which creates an ObjectManager using the
>> sd-bus API and there seems to be some differences between how gdbus and
>> sd-bus implements the API.
>> 
>> I implemented a simple ObjectManager at /org/gnome/TestManager which
>> exports objects /org/gnome/TestManager/fooX with interface
>> org.gnome.TestManager.Device.
>> 
>> Under sd-bus, if an object is removed, the following signal is
>> generated:
>> 
>> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
>> serial=90 path=/org/gnome/TestManager;
>> interface=org.freedesktop.DBus.ObjectManager;
>> member=InterfacesRemoved
>> object path "/org/gnome/TestManager/foo0"
>> array [
>> string "org.freedesktop.DBus.Peer"
>> string "org.freedesktop.DBus.Introspectable"
>> string "org.freedesktop.DBus.Properties"
>> string "org.freedesktop.DBus.ObjectManager"
>> string "org.gnome.TestManager.Device"
>> ]
>> 
>> If I implement the same simple server in gdbus, the signal is instead:
>> 
>> signal time=1492642227.714223 sender=:1.104 -> destination=(null destination)
>> serial=90 path=/org/gnome/TestManager;
>> interface=org.freedesktop.DBus.ObjectManager;
>> member=InterfacesRemoved
>> object path "/org/gnome/TestManager/foo0"
>> array [
>> string "org.gnome.TestManager.Device"
>> ]
>> 
>> The corresponding signals are also generated when an object is added.

>>> Does the appended patch fix your issue?
>>> (line-breaks might be screwed, sorry)
>> 
>> Haven't tried it yet, but just from reading the patch...it seems to do
>> the opposite of what I'd expect? I.e. add *more* interfaces?
> 
> This change makes sure all objects have the built-in interfaces
> reported at all times. The GetManagedObjects() call didn't report them
> so far.

Quite the contrary? If you look at the output from dbus-monitor above, you'll 
see that it is sd-bus that already *does* report all interfaces while gdbus 
doesnt?
 
> Note that we really better report all interfaces an object supports. I
> don't know why glib does not do this, but I think it should.

Maybe, I'm no dbus expert. And there does seem to be a bug in gdbus as well 
since the additional interfaces manage to confuse it. Anyway, it seems that 
either sd-bus should adapt the gdbus style or vice versa...maybe you could talk 
directly to the gdbus people?

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

Re: [systemd-devel] sd-bus: ObjectManager difference with gdbus

[David Härdeman]

April 24, 2017 4:51 PM, "Lennart Poettering"  wrote:

> On Fri, 21.04.17 13:22, David Herrmann (dh.herrm...@gmail.com) wrote:
> 
>> Anyway, gdbus bugs aside, it seems that the interfaces reported by
>> sd-bus should match what gdbus does? (assuming, of course, that gdbus
>> can be considered the "reference" implementation).
>> 
>> Does the appended patch fix your issue?
>> (line-breaks might be screwed, sorry)
>> 
>> Haven't tried it yet, but just from reading the patch...it seems to do
>> the opposite of what I'd expect? I.e. add *more* interfaces?
>> 
>> This change makes sure all objects have the built-in interfaces
>> reported at all times. The GetManagedObjects() call didn't report them
>> so far.
>> 
>> Note that we really better report all interfaces an object supports. I
>> don't know why glib does not do this, but I think it should.
> 
> Yeah, I#d agree with that. I think we should provide complete
> information, and that means including built-in interfaces in all our
> messages, in particular as some of them are optional. It appears to
> me, that gdbus should be changed here, not sd-bus...

In that case, no changes are necessary to sd-bus since it already exposes all 
interfaces.

I've filed a bug report against gdbus:
https://bugzilla.gnome.org/show_bug.cgi?id=781524

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

Re: [systemd-devel] Systemd --session instance?

[Benno Fünfstück]

>
> Increased complexity in *all* software — each and every thing you start
> must
> support multiple sessions.
>

Oh, why is that? I wasn't suggesting to replace the existing systemd --user
instance, only to add a new one for each session. So software that does not
support multiple sessions still does not have to: if firefox does not
support multiple sessions, then so be it, then that means you can only use
it on a single session and it continues to use the per-user instance. Or is
it not that easy?

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