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

[Lennart Poettering]

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...

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] systemd integration

[Lennart Poettering]

On Sat, 22.04.17 14:52, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> 
> Am 22.04.2017 um 13:28 schrieb John Doe:
> >   Free and Open-Source (FOSS
> >   )
> >   operating systems
> >   without systemd
> > 
> > http://without-systemd.org/wiki/index.php/Main_Page
> 
> and who cares about the "i love my decades old mess of unpredictable bash
> scripts nobody understands really"-users and how is this a topic here?
> 
> disclaimer: i am *not* a systemd developer but just annyoed from fools which
> don't understand systemd and act like vegans - unasked preach their "systemd
> is bad" religion

Reindl, please don't feed the trolls. Simply don't respond to mails
such as "John Doe"'s.

Lennart
___
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 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journal fragmentation on Btrfs

[Lennart Poettering]

On Sat, 22.04.17 15:29, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> 18.04.2017 07:27, Chris Murphy пишет:
> > On Mon, Apr 17, 2017 at 10:05 PM, Andrei Borzenkov  
> > wrote:
> >> 18.04.2017 06:50, Chris Murphy пишет:
> > 
>  What exactly "changes" mean? Write() syscall?
> >>>
> >>> filefrag reported entries increase, it's using FIEMAP.
> >>>
> >>
> >> So far it sounds like btrfs allocates new extent on every write to
> >> journal file. Each journal record itself is relatively small indeed.
> > 
> > Hence why it would be better if there's no fsync so that it can
> > accumulate these and do its own commit (30s default for Btrfs) and let
> > them accumulate.
> > 
> 
> It is not related to fsync. I made some tests. Journald does not appear
> to preallocate file nor mmap the whole file (at least as far as I can
> see from the source); when it appends new record it basically does
> 
> fallocate (fd, end_of_file, new_size)
> mmap (fd, end_of_file, new_size)
> write to new size
> 
> This results in large number of extents as each fallocate() ends up in
> new extent.
> 
> I can easily reproduce it with small program that is using similar
> pattern; actually mmap is also red herring. Just fallocat'ing file in
> small increments gives file consisting of overly large number of
> extents. How exactly those extents get distributed across device
> probably depends on overall filesystem activity.
> 
> This is different from simply writing to file at the end, which still
> results in several extent, but significantly larger.
> 
> BTW you get the same pattern from direct IO. Writing 100M file in 4K
> blocks using cached writes gives me here 7 extents of size between 25M
> and 500K. Writing the same with direct IO results in 25600 extents (same
> as growing file in 4K steps with fallocate).

BTW, we are not really married to any particular fancy semantics of
fallocate(). We call it mostly so that our later writes to the file
blocks using mmap() will not result in SIGBUS. There was also the hope
that letting the fs know in advance that we are about to append the
specified amount of bytes to the end of the file through mmap() would
be a good thing not a bad thing... Or in other words, we really don't
need fallocate() to actually go to disk or anything and actually write
anything. All we want is *reserve* some space for us...

Maybe this is something to report to the btrfs folks? It appears to me
their implementation of fallocate() does more than it has to according
to the docs.

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] Systemd --session instance?

[Lennart Poettering]

On Sat, 22.04.17 14:07, Benno Fünfstück (benno.fuenfstu...@gmail.com) wrote:

> Hello list,
> 
> currenty, systemd runs a system instance and a per-user one. However,
> sometimes it would be nice to have a per-session instance, for example for
> users of lightweight desktop environments that don't have their own service
> manager. Then you could use systemd to spawn things like panels or desktop
> notification daemons etc. Would it be possible to add such a thing, even if
> it may require some work? Or are there any fundamental problems with it?

As Zbigniew already pointed out this was a deliberate design decision
not to support. In the general case software can't really deal with
multiple sessions of the same users. Some fail in friendlier ways (for
example, web browsers tend to take a lock at startup thus ensuring
they are only started once per user) and others in unfriendlier
ways. Yes, there are select few programs which are entirely fine with
running multiple times for the same users, but these tend to be the
exception, not the rule, and are usually on the more simple side of
things, with anything more complex not supporting it.

The idea of moving to a single-graphical-session-per-use scheme doesn't
mean you are restricted to a single screen however. It just means
every hw you have (be it a kbd, a screen, a mouse, ...) would be
merged in one way or another into a single session. (i.e. in a
xinerama-style setup)... After all, between a user and himself sharing
should be a good thing, not a bad thing. 

Yes, this is not how X11 used to handle things, but I figure what we
can learn from history is that multiple sessions per user is too hard,
and too exotic for app developers to implement it correctly.

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] Systemd --session instance?

[Benno Fünfstück]

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.

* 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?

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

[systemd-devel] hibernation sometimes not working

[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?



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?

[Zbigniew Jędrzejewski-Szmek]

On Mon, Apr 24, 2017 at 08:09:00PM +, Benno Fünfstück 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.
> 
> 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?

> * 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.

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

Anyway, it's something that could be discussed until the heat death of
the universe. If you think this can work, add support to the DE of
your choice, build a bunch of unit files, and convince maintainers of
various programs to add necessary support (firefox, thunderbird,
libreoffice, and anything else which keeps nontrivial state). I think
it's fair to say that people on this list think that this goal is not
worth pursing.

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

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

[Trent Lloyd]

Hi Folks,

I ran into an issue when doing local development on Avahi where after 
the following sequence of events I could no longer connect to 
/run/avahi-daemon/socket activated by avahi-daemon.socket

 (1) systemctl disable avahi-daemon.service
 (2) systemctl stop avahi-daemon.service
 (2) sudo avahi-daemon --debug, then exit the process
 (3) systemctl start avahi-daemon.service
 [side note: if you try to reproduce this there is a chance a hostname 
lookup will trigger and connect to avahi-daemon.socket and activate it, 
meaning avahi-daemon won't manually start.  You'll have to avoid that; 
stopping avahi-daemon.socket would invalidate the issues noted below]


When avahi-daemon is started manually (without systemd), it does not 
receive an FD and instead unlinks and replaces the socket. 
avahi-daemon.socket is left running and never restarted, the now stale 
socket (no longer actually linked to the on-disk file) is still passed 
to avahi-daemon.service when it is started again and the socket does not 
work.  A restart of avahi-daemon.socket does fix that.


I'm wondering if I can improve this situation and what the "Right Way" 
is.  I think it's a little muddy generally as effectively I am messing 
with the system outside of systemd but given the general recommended 
socket activation workflow to bind the socket if it's not passed in, 
this does not seem entirely unlikely to happen in some cases. And the 
result is surprising and confusing on inspection to the average user, 
the socket exists but does not work even after restarting 
avahi-daemon.service.



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.


(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)



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.


Any input appreciated.

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

Re: [systemd-devel] hibernation sometimes not working

[Andrei Borzenkov]

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.



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