Re: [systemd-devel] Session-specific user services

2021-04-06 Thread Simon McVittie
On Fri, 02 Apr 2021 at 20:54:05 +0300, Arseny Maslennikov wrote:
> There's at least a use case to know if an active session owned by the
> UID is present on seat X:
> In short, if a USB storage drive is connected to a particular seat,
> we'd like to only try automounting it on that seat, and not on a random
> seat that wins a race condition.

Consider this system:

uid 1000
   \- login session 1 on seat 1
   \- GNOME
   \- login session 2 on seat 2
   \- getty/bash
   \- systemd --user
   \- gvfsd process 1
uid 2000
   \- login session 3 on seat 3
   \- GNOME
   \- login session 4 on seat 4
   \- getty/bash
   \- systemd --user
   \- gvfsd process 2

(Note that this is already a bit silly because each of uid 1000 and uid
2000 presumably represents a person, and at any given time, that person
is physically sitting in at most one seat...)

If gvfsd is a `systemd --user` service, then there are two instances of it:
one for uid 1000, and one for uid 2000. It is *not* the case that there are
four instances of it, one per seat.

Now we plug a USB drive into seat 3, and another USB drive into seat 4.
Suppose both users have configured gvfsd to automount USB drives. What
we want is that uid 1000 does not mount either of the USB drives (even
if they have the necessary permissions), and uid 2000 mounts both of them.

You seem to be suggesting that the right logic is for each gvfsd instance
to run this pseudocode:

# Here get_login_session() is assumed to return non-null even if the
# process is a systemd --user service. Will it return 3 or 4 for
# uid 2000's gvfsd? It can only return one of those!
if this_process.get_login_session().seat ==

I don't think that's right, though: assuming get_login_session() is
deterministic, we will only automount *either* the USB drive on seat 3
*or* the one on seat 4, not both.

I think the logic we want in gvfsd is probably more like this:

for login_session in this_uid.get_login_sessions():
if ==

Or, perhaps even better:

# This time we want this to return null if this process is a
# systemd --user service
login_session = this_process.get_login_session()

if login_session:
# traditional D-Bus activation, or XDG autostart, or run in the
# foreground for development/debugging; responsible for only its
# own login session
if ==
# systemd --user service, shared by all our login sessions
for login_session in this_uid.get_login_sessions():
if ==

either of which will do the right thing: uid 1000 will not automount either
of the USB sticks (even if they have permissions to do so), and uid 2000
will automount both of them.

systemd-devel mailing list

Re: [systemd-devel] sdbus errors and their underlaying int value: unique?

2021-03-03 Thread Simon McVittie
On Wed, 03 Mar 2021 at 13:51:38 +0100, Lennart Poettering wrote:
> On Di, 02.03.21 10:40, Carlo Wood ( wrote:
> > In C++ we have std::error_code which stores both a (unique) domain
> > and an int that is defined within that domain. The integer values
> > do not have to be globally unique.
> Generally: when doing D-Bus focus on the error names, because that's
> the native thing.

It seems std::error_code is conceptually the same as the domain and code
from GLib's GError (convergent evolution, or inspiration from GLib?),
so it would probably be useful to look at how GLib's GDBus maps GError
to/from D-Bus errors:

In GError, the domain is basically a string (it's a GQuark, which is a
handle representing an "interned" string), the code is an int defined
within that domain, and there is also a human-readable message. So for
instance, org.freedesktop.DBus.Error.NoMemory maps to
(domain=G_DBUS_ERROR, code=G_DBUS_ERROR_NO_MEMORY), which behind the
scenes is the same as
(domain=g_quark_from_string("g-dbus-error-quark"), code=1).

systemd-devel mailing list

Re: [systemd-devel] Debugging sd_notify / tracing notifications?

2021-03-02 Thread Simon McVittie
On Mon, 01 Mar 2021 at 10:20:31 -0500, John Ioannidis wrote:
> I occasionally need to send a SIGINT to the process

Have you tried this?

systemctl kill --signal=SIGINT foo.service

(Perhaps with --kill-who=main if you just want to kill its top-level
process and not its child processes, if any)

systemd-devel mailing list

Re: [systemd-devel] Still confused with socket activation

2021-02-04 Thread Simon McVittie
On Thu, 04 Feb 2021 at 13:07:33 +0100, Reindl Harald wrote:
> "Requires=a.service" combined with "Before=a.service" is contradictory -
> don't you get that?

It means what it says: whenever my service is enabled, a.service must
also be enabled, but my service has to start first (and stop last).

For instance, imagine this scenario:

* my service sets something up that will trigger an action later:
  perhaps it creates a configuration fragment in a.conf.d

* any number of other services might be doing the same as my service

* whenever at least one service has done that, when they have all finished
  doing their setup, we need to start a.service, which will take those
  triggers (e.g. contents of a.conf.d) and "commit" whatever is needed
  for all of them

* if multiple services have set up a triggered action, we only want to
  run a.service once, and it will act on all the triggers as a batch

Then my service should have Requires=a.service (because if a.service
never runs, the "commit" action will never happen and my service will
not do what I wanted); and it should have Before=a.service (because the
triggers need to be in place before a.service processes them).

dpkg and RPM triggers are not (currently!) systemd services, but they
work a lot like this. They're typically used to regenerate caches.

Another reason to combine Requires with Before is that Before is really
a short name for "start before and stop after", and After is really a
short name for "start after and stop before". If you're dealing with
actions taken during system shutdown or session logout, the stop action
might be the one that does the real work, making it more likely that
Before dependencies are the important ones.

systemd-devel mailing list

Re: [systemd-devel] What exactly is multi-seat? -- questions about logind

2021-01-26 Thread Simon McVittie
On Tue, 26 Jan 2021 at 01:43:43 -0800, Kian Kasad wrote:
> First of all, what exactly is multi-seat? Does it just mean allowing
> multiple sessions to be running at once, like for multiple users to be
> logged into the same desktop, even though only one will be in use at a
> time?

No, that's "fast user switching" (usually implemented in terms of
virtual consoles).

Multi-seat is when you have one PC with two screens and two keyboards,
Alice sits in front of screen A and types into keyboard A, Bob
simultaneously sits in front of screen B and types into keyboard B.
Both people interact with their own desktop environment, neither person
interacts with the other desktop environment, and there is a security
boundary protecting each user from the other.

Usually they each get their own set of USB ports, and Alice can plug
in USB devices (in particular storage devices) without giving Bob access
to them.

> Second, why is logind needed for this? Is it not possible to do without
> logind?

You need either logind or something roughly equivalent to logind, to
manage which screen, keyboard, mouse etc. belong to Alice and which set
belong to Bob, and keep them separate. It doesn't *necessarily* have
to be logind, but there needs to be a component with a vaguely similar
role. The obsolete ConsoleKit (which was superseded by systemd-logind)
was an older implementation of multi-seat.

elogind probably implements multi-seat too, but this is the systemd
mailing list, not the elogind mailing list.

> Most of these questions arose because my main OS, Artix Linux, requires
> logind (in the form of elogind) for Xorg, but I know that Xorg runs just
> fine on Alpine Linux, which does not use logind at all.

There are a lot of subtleties beyond "runs just fine". If Artix Linux has
chosen to offer features that require a logind implementation, then they'll
need a logind implementation. If Alpine Linux has chosen to treat those
features as outside their scope, then they won't need logind.

(Also, this is the systemd mailing list, not the elogind or Artix mailing
list; if you are unsure about elogind's capabilities or why Artix requires
it, I would suggest asking elogind or Artix people.)

systemd-devel mailing list

Re: [systemd-devel] ssh.service in

2020-11-09 Thread Simon McVittie
On Mon, 09 Nov 2020 at 09:16:05 -0500, Phillip Susi wrote:
> I guess I'll try masking it.

The Debian/Ubuntu package for systemd already masks various services
that are superseded by something in systemd, such as procps.service and
rcS.service. It used to also mask all the services from initscripts,
but that seems to have been dropped in version 243-5.

systemd-sysv-generator (which generates systemd service units corresponding
to sysv-rc services) has stopped generating units for sysv-rc services that
run in rcS, rc0 and rc6, but still generates units for rc1 (mapped to killprocs runs in rc1.

Perhaps the systemd Debian/Ubuntu package still needs to mask rc1 services
like killprocs, or perhaps the initscripts package should take over
responsibility for masking rc1 services that it ships if they are not
applicable to systemd, or perhaps systemd-sysv-generator should ignore
services like killprocs that run in rc1?

> apt-cache depends util-linux says that it does not
> *depend* on it but *replaces* it.  Doesn't that mean that when
> util-linux is installed, initscripts should be removed?

Not necessarily, it isn't the same as RPM's Obsoletes field.
"util-linux Replaces initscripts" means that util-linux is allowed to
overwrite files that were previously shipped in initscripts. The rest
of initscripts is potentially still necessary (in fact it's unnecessary
when booting with systemd, but necessary when booting with sysv-rc).

Also, the Replaces is versioned: only old versions of initscripts are
replaced, and new versions are unaffected.

> initramfs-tools does not depend on initscripts, but *breaks* it, which
> should mean it is not possible for both packages to be installed at the
> same time.

initramfs-tools only Breaks initscripts (<< 2.88dsf-59.3~), which means
it is possible for both to be installed at the same time, as long as
initscripts is at a sufficiently new version.

systemd-devel mailing list

Re: [systemd-devel] systemctl reboot/halt with non-privilege user

2020-10-28 Thread Simon McVittie
On Wed, 28 Oct 2020 at 14:11:07 +0200, Mantas Mikulėnas wrote:
> I'm not entirely sure why reboot is treated differently from halt, though.

If you reboot a machine, it will (hopefully!) come back up after some
downtime, so it's a limited level of denial of service and might make sense
to restrict a little less than poweroff and halt.

If you power off a machine, someone needs to go and press the power button
to bring it back up (unless you have proper server infrastructure with
remote-power-cycle capabilities), so it's a stronger denial-of-service
if this happens on a remote machine.

If you halt a machine, it will halt the OS kernel and hang (not fully
powered-off, still consuming power) which in my experience is rarely what
you actually wanted, but the practical impact is similar to poweroff.

systemd-devel mailing list

Re: [systemd-devel] Crond session, pam_access and pam_systemd

2020-10-13 Thread Simon McVittie
On Tue, 13 Oct 2020 at 13:09:43 +0200, Thomas HUMMEL wrote:
> Ok, so for instance, on my debian, when I see:
> > user@1000.service
> │   │ ├─gvfs-goa-volume-monitor.service
> │   │ │ └─1480 /usr/lib/gvfs/gvfs-goa-volume-monitor
> │   │ ├─gvfs-daemon.service
> │   │ │ ├─1323 /usr/lib/gvfs/gvfsd
> │   │ │ ├─1328 /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
> │   │ │ └─1488 /usr/lib/gvfs/gvfsd-trash --spawner :1.19
> /org/gtk/gvfs/exec_spaw
> │   │ ├─gvfs-udisks2-volume-monitor.service
> │   │ │ └─1453 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
> │   │ ├─xfce4-notifyd.service
> │   │ │ └─1355 /usr/lib/x86_64-linux-gnu/xfce4/notifyd/xfce4-notifyd
> those services jobs are started by the systemd --user in this user init
> scope, correct  ?

Yes. In many cases they're started on-demand (for example because
something talks to them over D-Bus) rather than being started "eagerly".

> My understanding now after your explanation is that crond, in the case of a
> user crontab and pam_systemd in the crond stack, will create a session and
> thus instanciate a systemd --user if not already present (like in the
> lingered case)

Yes. If uid 1000 is already logged in or is flagged for lingering,
and a cron job for uid 1000 starts, the cron job will reuse their
pre-existing systemd --user. If uid 1000 does not already have a
systemd --user, crond's PAM stack will result in a systemd --user being
started before the cron job, and stopped after the cron job.

> Do you confirm that, in the case of crond this systemd --user is useless ?

It might be useful, it might be useless. It depends what's in your
cron jobs.

For example, if you have a cron job that uses GLib to act on SMB shares or
trashed files or anything like that, then it will need gvfs-daemon.service
(just like the fragment of a process tree you quoted above) to be able
to access smb:// or trash:// locations.

systemd-devel mailing list

Re: [systemd-devel] A sh -c '${name} and $name' are treated inconsistently within a .service unit

2020-08-27 Thread Simon McVittie
On Thu, 27 Aug 2020 at 16:11:37 +, wrote:
> ExecStart=/bin/bash -c 'set -x; declare -r str="1 2"; echo ${str}; echo $str; 
> exit 0;'

This seems to be behaving as documented:

   Basic environment variable substitution is supported. Use "${FOO}" as
   part of a word, or as a word of its own, on the command line, in which
   case it will be erased and replaced by the exact value of the
   environment variable (if any) including all whitespace it contains,
   always resulting in exactly a single argument. Use "$FOO" as a separate
   word on the command line, in which case it will be replaced by the
   value of the environment variable split at whitespace, resulting in
   zero or more arguments.
   — systemd.service(5)

The single-quoted string is considered to be a "word" here.

The string is parsed by systemd, and the result of parsing is inserted
into bash's argv and parsed again by bash. It's the same as the way
you have to write shell variables as $$foo if you are embedding a shell
script in a Makefile, or the way you have to escape backslashes multiple
times if you want to write a regular expression that matches backslashes,
inside a double-quoted shell string, inside a C string (add as many more
levels of embedding as you want, or see

If you want to write shell or Perl scripts, or other constructs that
*also* use $ as special syntax, then you will need to either escape all
occurrences of $ that you don't want systemd to interpret (write them
as $$, like in make), or put your shell script in a separate file and
reference it from the systemd unit.

systemd-devel mailing list

Re: [systemd-devel] Ensuring that a unit starts before any networking

2020-06-30 Thread Simon McVittie
On Tue, 30 Jun 2020 at 12:59:54 +0100, Mark Rogers wrote:
> On Tue, 30 Jun 2020 at 12:13, Simon McVittie  wrote:
> >
> > I would have expected this to be done in some "larger" network management
> > component that is responsible for bringing up network interfaces according
> > to your configuration, rather than necessarily dhcpcd.service itself.
> In which case one would expect dhcpcd to depend on that instead

I meant the other way around, actually: a larger network management
component like ifupdown (which has policy, not just mechanism) tells
dhcpcd to start managing an interface, and that larger component
conceptually depends on dhcpcd. (It might not be an explicit dependency
because of automatic activation.)

Adding to dhcpcd.service is probably also not
a bad idea. It isn't clear to me whether dhcpcd brings up interfaces of
its own accord just because you start it as a systemd unit, or whether
it brings up interfaces only when specifically requested by something
like ifupdown or NetworkManager, or some mixture. If it can be configured
to bring up interfaces on its own, independent of things like ifupdown,
then it is taking on at least part of the role of a network management
component itself, in which case it does need

> > Typically server-class systems will use either ifupdown or
> > systemd-networkd, which are ideal for relatively static network
> > configurations that are set up by a sysadmin.
> It's definitely not systemd-networkd, to my untrained eye it looks
> like ifupdown is there but how do I confirm?

Your unit in
(which I missed when replying earlier) refers to networking.service,
which is part of ifupdown.

Depending on precisely what configuration you're writing out from your
database in your use-case-specific unit, you might be configuring
ifupdown to do things (in which case ifupdown's
should be enough), or you might be configuring dhcpcd to go behind
ifupdown's back to do things (in which case your use-case-specific unit
needs to happen before dhcpcd), or something else entirely. You'll need
to look at and understand the overall system you have set up.

You mentioned wanting to make your unit network-stack-agnostic, but
adding an extra layer of abstraction cannot solve all problems, and in
particular it cannot solve the problem "too many layers of abstraction".
At some point someone or something has to make a decision and actually
do something concrete :-)

systemd-devel mailing list

Re: [systemd-devel] Ensuring that a unit starts before any networking

2020-06-30 Thread Simon McVittie
On Tue, 30 Jun 2020 at 11:27:30 +0200, Lennart Poettering wrote:
> On Sa, 27.06.20 15:54, Mark Rogers ( wrote:
> > Adding to dhcpcd.service seems to have
> > resolved it, and taught me a lesson in the process.
> >
> > Is there an obvious reason I'm missing why these aren't distro
> > defaults? (Is this a "bug" in the network management tools' unit
> > files? Would "fixing" this at the distro level have any likely side
> > effects?)
> Yes, this is a bug in the the distro packaging. Please file a bug
> against your distro, so that they add

I would have expected this to be done in some "larger" network management
component that is responsible for bringing up network interfaces according
to your configuration, rather than necessarily dhcpcd.service itself.

You mentioned Raspbian, which is a Debian derivative? On Debian systems,
network device management is typically provided by either ifupdown (the
traditional/historical network management component in Debian),
systemd-networkd, NetworkManager or wicd. If those aren't After, then they should be.

Typically server-class systems will use either ifupdown or
systemd-networkd, which are ideal for relatively static network
configurations that are set up by a sysadmin. Portable/roaming systems
like laptops will typically use either NetworkManager or wicd, which
are ideal for dynamic network configuration through a GUI (and in
particular, some desktop environments like GNOME have built-in support
for NetworkManager). Desktop and embedded systems could go either way.

In ifupdown, the networking.service and ifup@.service units are ordered, which I think should be sufficient.
NetworkManager.service and systemd-networkd.service also look correct.
However, wicd does not currently appear to have implemented this (I've
opened a Debian bug).

If Raspbian does its own thing rather than recycling Debian components
for this, then it might need a separate bug report.

systemd-devel mailing list

Re: [systemd-devel] Q: daemon-reload: when and how?

2020-06-18 Thread Simon McVittie
On Thu, 18 Jun 2020 at 11:01:59 +0200, Jérémy ROSEN wrote:
> multiple unit files need to work together to make a working environment, and
> systemd can't know when all changes are consistent and
> it is safe to reload. So systemd will want an explicit order from the user.

Also, reloading is disruptive and can be "expensive" in terms of resource
use. If you're making a lot of changes (like an upgrade transaction in
a package manager like apt or RPM), you probably want to do the entire
transaction, and then reload *once*.

dbus-daemon *does* automatically reload when configuration or service files
change. People now expect/rely on this, so it's undesirable to change,
but with hindsight I wish it didn't. I think the fact that systemd *doesn't*
automatically reload is partly learning from dbus-daemon's mistake.

On Thu, 18 Jun 2020 at 12:43:59 +0200, Ulrich Windl wrote:
> Is there something like "systemd suggests daemon-reload" (assuming systemd
> detects the situation, but does not issue a reload itself)?

Yes there is:

$ systemctl status dbus.service
(... some information here ...)
$ sudo touch /lib/systemd/system/dbus.service
$ systemctl status dbus.service
Warning: The unit file, source configuration file or drop-ins of
dbus.service changed on disk. Run 'systemctl daemon-reload' to reload
(... same status information ...)

In this case I didn't really alter /lib/systemd/system/dbus.service,
just changed its mtime, but you'd get the same thing from an edit that
actually matters.

systemd-devel mailing list

Re: [systemd-devel] --Reboot-- lines in journal

2020-05-14 Thread Simon McVittie
On Thu, 14 May 2020 at 16:12:49 +0300, Mantas Mikulėnas wrote:
> The "--Reboot--" line is simply shown every time the _BOOT_ID field changes
> between two entries -- even if it changes to a previously seen boot ID (which
> shouldn't happen normally, but *might* be caused by lack of a RTC?).

The Raspberry Pi doesn't have a real-time clock, so if the journal
is sorting log entries by their claimed timestamp rather than by the
order in which they were actually written, it's entirely possible that
different boots will get interleaved.

In a traditional syslogd-style log file where entries are written in
order, you'd see the wallclock time jump backwards at each reboot,
then jump forwards again when NTP/etc. resynchronizes.

systemd-devel mailing list

Re: [systemd-devel] os-release: extension to expose host's version variables to containers

2020-05-06 Thread Simon McVittie
On Wed, 06 May 2020 at 16:39:39 +0200, Lennart Poettering wrote:
> On Do, 16.04.20 16:56, Simon McVittie ( wrote:
> > /run/host seems like a reasonable convention to encourage for
> > container/host systems that want this, since it doesn't require
> > inventing a new top-level directory.
> I am not opposed adding something similar to nspawn, using the same
> paths. Only issue I see: docker doesn't acknowledge the existance of
> /run inside the container iirc, i.e. doesn't pre-mount it, hence
> passing data in via some subdir in /run is weird...

I suspect Docker itself probably isn't going to implement this interface,
because it doesn't generally acknowledge the existence of non-Docker
container frameworks, and sharing information from the host with the
container is pretty much the opposite of its philosophy in any case.

If *users of Docker* want to implement this interface, they can do so
with something like

docker run \
--mount type=tmpfs,tmpfs-mode=0755 \
--mount type=bind,src=/etc/os-release,dst=/run/host/etc/os-release,ro \

in much the same way they can implement the "/run is a tmpfs"
interface, or the various desirable properties listed in
<>, by giving Docker suitable

They'd have to pass similar options to Docker to get /host (which was the
original suggestion in this thread), so the conventional directory might
as well be one that doesn't need to invent new top-level directories?

systemd-devel mailing list

Re: [systemd-devel] os-release: extension to expose host's version variables to containers

2020-04-16 Thread Simon McVittie
On Thu, 16 Apr 2020 at 14:03:43 +, Luca Boccassi wrote:
> But I found at least one other use case where this is needed, and the
> solution there is to add a new directory /host/ which replicates part
> of the host's filesystem tree, including os-release:

Flatpak uses /run/host for similar things. Some parts of the host system
are visible to Flatpak apps unconditionally, and some only if the Flatpak
app has special permission flags.

In particular, if a Flatpak app has the --filesystem=host permission flag
(which is mainly intended to expose the host's /home, /srv, /media etc. in
the container's /home, /srv, /media etc., for apps that can't be sandboxed
properly), the host's /usr and /etc get exposed in /run/host/usr and

In the Flatpak 1.7 development branch, I added a host-os permission,
which puts the host /usr in /run/host/usr, the host /bin, /sbin and /lib*
(if not /usr-merged) in /run/host/bin etc., and a small subset of /etc
(, alternatives) in /run/host/etc; and a host-etc permission,
which puts the whole host /etc in /run/host/etc. Those can be used to
share the host OS, without the side-effect of sharing users' personal

/run/host seems like a reasonable convention to encourage for
container/host systems that want this, since it doesn't require
inventing a new top-level directory. The experimental pressure-vessel
container-runner, used in Steam to run games in containers, also uses

That setup would automatically let apps with appropriate permissions read
/run/host/etc/os-release and/or /run/host/usr/lib/os-release to get host
OS properties.

systemd-devel mailing list

Re: [systemd-devel] Stateless system - Centos8 and overlayfs on root

2020-03-30 Thread Simon McVittie
On Fri, 27 Mar 2020 at 10:17:37 -0700, Preston L. Bannister wrote:
> Updates would be accomplished by booting from the original boot menu entry.
> (This is slightly complicated by the fact the target systems' computers do not
> have a console - but figure I can script altering the default boot.)

I think you might be better off with something based on the idea of
building an immutable "golden image" elsewhere, and deploying it to the
stateless machines using a filesystem-image-based "A/B" update strategy
(like casync and Android) or a filesystem-tree-based atomic update
strategy (like libostree, as used in Fedora Silverblue and Endless).
Either way, the big ideas are:

- build the "golden image" in CI infrastructure somewhere else
- have enough space for two complete OSs
- whichever one you are booted into (let's say it's "A"), overwrite the
  other one (let's say "B") with the new OS
- reboot into "B", but just once (have a clever bootloader)
- if "B" fails to boot, recover by going back to "A"
  - you hope that a later upgrade will fix the regression and overwrite
"B" again, this time with a better version
- if "B" boots OK, keep using it (tell the bootloader to boot it every
  time from now on); next time you upgrade, swap the roles of "A" and "B"

Most people who do that will be using an overlay-like arrangement to
store whatever state they want to transfer between A and B, such as /etc
and /home - but in your case you don't want to store any state at all.

systemd-devel mailing list

Re: [systemd-devel] Reasoning behind sd_bus_error argument to sd_bus_call?

2020-03-18 Thread Simon McVittie
On Tue, 17 Mar 2020 at 20:17:05 +0100, Daan De Meyer wrote:
> I'm documenting sd_bus_call and its async variant and I was wondering about 
> the
> sd_bus_error output parameter that's passed to it. [...] I don't
> see immediately see the benefit of the sd_bus_error parameter in a D-Bus 
> client
> since I can simply check the return value instead which seems to contain the
> same information looking at the implementation.

The return value is a single int, which according to systemd conventions
is probably a negative errno value. That's a lot less information than
a D-Bus error (systemd sd_bus_error, libdbus DBusError or equivalent):
D-Bus errors consist of a machine-readable name (namespaced by a reversed
domain name) and a human-readable message.

For the information about *whether* an error occurred, sure, you get the
same information, but for information about *which* error occurred and why,
a sd_bus_error is a lot better.

Let's pretend your D-Bus client is interacting with a D-Bus service that
resembles systemd-timedated. An errno value can give you, at best,
something like this (where *** marks the part that came from the service's

my-client: Error: Unable to set time zone to America/Gotham:
***No such file or directory (errno 2)***

whereas a D-Bus error (sd_bus_error) from a well-implemented service can
give you something a lot more detailed. For example, after you ispect
the sd_bus_error, you might find that the error above was either of these:

my-client: Error: Unable to set time zone to America/Gotham:
***No time zone file for "America/Gotham" found (tried
(error code com.example.NotTimedated.Error.NoSuchTimezone)***

my-client: Error: Unable to set time zone to America/Gotham:
***No time zone data installed (tried "/usr/share/zoneinfo",
(error code com.example.NotTimedated.Error.TzdataNotInstalled)***

In this example a programmatic client would also be able
to respond differently to the distinct machine-readable
errors com.example.NotTimedated.Error.NoSuchTimezone and
com.example.NotTimedated.Error.TzdataNotInstalled if it wanted to;
for example it could respond to the second error by trying to use
PackageKit to install tzdata, which obviously wouldn't be appropriate
for the first error.

D-Bus errors were inspired by GLib's GError, which is basically a triple
{ domain: interned string, code: int, message: string }, where the domain
provides extensible uniqueness, and the code is a member of an enum
determined by the domain.

systemd-devel mailing list

Re: [systemd-devel] dbus activation service path

2020-01-27 Thread Simon McVittie
On Fri, 24 Jan 2020 at 23:27:20 +0200, Damian Ivanov wrote:
> I also have a question about dbus activation.
> Is there an environment variable or something to tell systemd/dbus-broker 
> to look in a specific path for dbus .service files?

The D-Bus Specification[1] says:

 On Unix systems, the session bus should search for .service files in
 $XDG_DATA_DIRS/dbus-1/services as defined by the XDG Base Directory
 Specification. Implementations may also search additional locations,
 with a higher or lower priority than the XDG directories.

so you should set the environment variables XDG_DATA_HOME and/or
XDG_DATA_DIRS, the same way you set those variables to influence the
search path for .desktop files. See [2] for more information.

If a piece of software that reads session service definition files does
not do this, please report that as a bug in that piece of software, using
its bug tracking system. In particular, if you believe dbus-broker has
a bug in this area, reporting it in flatpak's bug tracker is unlikely
to get it seen or fixed by dbus-broker developers.


systemd-devel mailing list

Re: [systemd-devel] EXT: sdbus_event loop state mark as volatile?

2019-09-06 Thread Simon McVittie
On Fri, 06 Sep 2019 at 06:57:22 +, Ray, Ian (GE Healthcare) wrote:
> If thread-safety is a design goal (and I don’t believe that it is [1])
> then atomic or thread-safe primitives should be used.
> [1] 

[1] is about sd-bus, not sd-event, and doesn't say anything about whether
sd-event is designed to be thread-safe or not.

However, I think you're correct to say that struct sd_event is also only
designed to be used from the single thread that "owns" it.

If you need a thread-safe event loop, then you need something like
GLib's GMainContext, with mutexes to protect its data structures against
concurrent access, and a well-defined mechanism for one main-context to
"post" events to other main-contexts (which might be running concurrently
in a different thread). Many other event loops are available; GMainContext
happens to be the one I'm most familiar with, and I know that it is
designed to be thread-safe.

The price that things like GMainContext pay for being thread-safe is
that they are more complex and less efficient than sd-event: in general,
all operations on a thread-aware event loop have to pay the complexity
and performance cost of being thread-aware, even if the current program
only has one thread.

systemd-devel mailing list

Re: [systemd-devel] Antw: Re: Need help detecting local/remote targets

2019-08-21 Thread Simon McVittie
On Wed, 21 Aug 2019 at 08:02:39 +0200, Ulrich Windl wrote:
> >>> Mantas Mikulenas  schrieb am 21.08.2019 um 06:07 in
> Nachricht
> :
> > / and /usr are mounted by initramfs before systemd starts.
> And what about /run?

/run is mounted by systemd as pid 1, but it is one of the "API file
systems"[1] and is required to be a tmpfs, so listing a non-tmpfs /run in
/etc/fstab is not a supported situation. As a result, it is always local.


systemd-devel mailing list

Re: [systemd-devel] systemd's connections to /run/systemd/private ?

2019-08-14 Thread Simon McVittie
On Wed, 14 Aug 2019 at 10:26:53 -0400, Brian Reichert wrote:
> And, if I were to ever use daemonize(1), or any other other canonical
> mechanism for daemonizing code, STDOUT would normally be closed
> under those circumstances, as well.

Doesn't daemonize(1) make stdin, stdout and stderr point to /dev/null,
instead of closing them? That's what glibc daemon(3) does, and seems
a lot better as a way to not break subprocesses' expectations. The man
pages of the daemon(1) and daemonize(1) in Debian[1] also both say they
do this, and it's what is recommended in systemd's own daemon(7).

Expecting arbitrary subprocesses to cope gracefully with being invoked
without the three standard fds seems likely to be a losing battle.
I've implemented this myself, in dbus; it isn't a whole lot of code,
but it also isn't something that I would expect the authors of all CLI
tools to get right. dbus only does this because X11 autolaunching can
lead to dbus-daemon being invoked in a broken execution environment, and
I would have considered the equivalent bug in most tools to be WONTFIX.

Expecting arbitrary *library code* to cope gracefully with being invoked
without the three standard fds seems like a non-starter, because these
fds are process-global state, so library code cannot safely mess with
them unless specifically asked to do so by the calling process.

In general library code can't do this safely anyway, because as soon as
the process has a second thread, it becomes impossible to fix the fds
in one thread without risking breaking another thread - this is one of
the operations that is usually only safe to do right at the beginning
of main(), similar to setenv().


[1] I'm sure there are lots of other executables named daemon or daemonize
in other OSs, and perhaps some of them get this wrong?
systemd-devel mailing list

Re: [systemd-devel] keyrings and dbus

2019-06-13 Thread Simon McVittie
On Thu, 13 Jun 2019 at 15:43:36 +0300, Topi Miettinen wrote:
> The sessions with slightly different scopes might be useful in some cases.
> But if this is not the case, would it be possible to unify the scopes and
> make systemd --user part of the login session?

I don't think so. Consider these two scenarios, which I hope you'll agree
should both be allowed:

* ssh user@mymachine
* with the ssh session still open, log in to gdm on mymachine as user

* log in to gdm on mymachine as user
* with the X11 or Wayland session still open, ssh user@mymachine

If systemd --user is part of a login session, then in each case it would
have to be started as a child process of the first way you logged in.
This would result in your dbus-daemon --session and your
gnome-terminal-server belonging to your ssh login session in the first
scenario, and your graphical login session in the second (even though
in both cases, gnome-terminal-server is drawing windows onto your
graphical login session).

It gets even weirder if you log out from the first login session, leaving
the second one logged in, and the long-running systemd --user and
dbus-daemon --session as members of a login session that no longer exists.

The "user-session" concept is primarily useful when login sessions overlap
like this: typically you'd have 0-1 graphical login sessions (gdm, etc.),
0 or more remote login sessions (ssh, etc.), 0 or more login sessions on
a virtual console or serial console (getty/login) and 0 or more cron jobs.

> Or the reverse, start the login session by systemd --user?

systemd --user is unprivileged and does not provide a transition from
not-logged-in to logged-in state (it isn't in the same position as login,
sshd, gdm, cron etc.), so it cannot start login sessions.

systemd-devel mailing list

Re: [systemd-devel] keyrings and dbus

2019-06-12 Thread Simon McVittie
On Wed, 12 Jun 2019 at 19:57:39 +0300, Andrei Borzenkov wrote:
> 12.06.2019 19:18, Simon McVittie пишет:
> > systemd user services are not part of a particular login session. They
> > exist outside all login sessions (look at systemd-cgls).
> > 
> gnome-terminal surely *is* part of particular login session.
> Unfortunately it is spawned by gnome-terminal-server which itself is
> started as systemd user session inside sytsemd-user ... session?

The gnome-terminal launcher stub (/usr/bin/gnome-terminal) is part of
a particular login session, but does not persist beyond startup. All it
does is to communicate with gnome-terminal-server and then exit.

gnome-terminal-server exists outside the scope of any particular login
session, and is the component that actually draws windows and runs
a shell.

This has the consequence that GNOME Terminal windows, and the shell that
runs inside them, are drawn onto the X11 or Wayland display that belongs
to a login session, but are not actually part of that login session. You
can see this by looking at the process and cgroup hierarchies.

> > It's your choice - but you can't have it both ways. The dbus-daemon
> > can't be both inside a login session, and shared between login sessions.
> But that means that as long as there are applications that are part of
> user session and started by dbus-daemon, dbus-daemon simply cannot be
> part of systemd-user, correct?

I'm very deliberately using the term "login session" because it is a
jargon term identifying a specific thing in the conceptual model used
by systemd-logind, which is essentially the same as the conceptual model
used by non-systemd things like PAM and Linux audit.

A process enters a login session in privileged code (like login(1) or gdm
or similar) at the transition between "not logged in" and "logged in". All
children of a process that is in a login session are in the same login
session; if a process that is not in any login session starts a child
process, the child is also not in any login session, unless the parent
process is privileged and is deliberately starting a new login session.
In systemd, a login session is represented by the session-$N.scope cgroup,
where $N is the session ID.

"User session" means something different: in D-Bus, we use it to refer
to the collection of processes belonging to a user who currently has
at least one login session. It includes all their login sessions (even
if there is more than one), as well as things that belong to that user
but are not in a login session, like systemd --user. In systemd, a user
session is represented by the user-$UID.slice cgroup, where $UID is the
user's numeric uid.

systemd --user is not part of a login session. If you are starting
dbus-daemon --session as a child process of systemd --user, then the
definitions above mean that the dbus-daemon is not part of a login
session either.

(dbus-daemon is never part of systemd --user - it's a separate process
running a separate executable - but it can be a child process of
systemd --user, or not, depending whether you started it using its
systemd user unit or via dbus-launch or some other way.)

If dbus-daemon is outside the login session, and you are also starting
applications via D-Bus activation, like gnome-terminal-server (either as
child processes of dbus-daemon, or as child processes of systemd --user
via dbus-daemon's support for delegating activation to systemd), then
those processes are also not part of a login session - even though they
might be drawing their X11 or Wayland windows as though they were! Again,
this is a consequence of the definition used for a login session: it is
defined in terms of the process hierarchy, not the X11 or Wayland display,
so connecting to a login session's X11 or Wayland display cannot make
you part of that login session.

systemd-devel mailing list

Re: [systemd-devel] keyrings and dbus

2019-06-12 Thread Simon McVittie
On Wed, 12 Jun 2019 at 18:34:30 +0300, Andrei Borzenkov wrote:
> Technically this is probably correct - session keyring lifetime is
> exactly that - session, and systemd-user lifetime is independent of
> individual (GUI) login session lifetime. But then D-Bus should not be
> started inside systemd-user "session", because lifetime of D-Bus user
> instance is supposed to be the same as user login session.

If you want the lifetime of the D-Bus session bus `dbus-daemon --session`
to be the same as a single graphical login session, either don't configure
it with --enable-user-session, or don't install its systemd user units
(packaged separately as dbus-user-session in Debian and its derivatives).

The scope of the D-Bus session bus is an OS integrator choice. It can
either be the same as a single login session, or the same as `systemd
--user`, but it cannot be both.

Of course, if its scope is the same as a single login session, then you
can't use it to communicate with `systemd --user` or use it from user
services, because they would be outside its scope.

> Or D-Bus
> needs explicit support for passing session keyring information when
> invoking user service that is part of user login session.

systemd user services are not part of a particular login session. They
exist outside all login sessions (look at systemd-cgls).

If you configure dbus with --enable-user-session, then D-Bus session
services are not part of a particular login session either.

It's your choice - but you can't have it both ways. The dbus-daemon
can't be both inside a login session, and shared between login sessions.

systemd-devel mailing list

Re: [systemd-devel] Anybody care to fix the list processor?

2019-06-11 Thread Simon McVittie
On Tue, 11 Jun 2019 at 15:44:07 +0200, Ulrich Windl wrote:
> Does anybody running the list care to fix the list-processor.

I don't think the members of this list
control its infrastructure, but I've opened

systemd-devel mailing list

Re: [systemd-devel] Password agent for user services

2019-05-28 Thread Simon McVittie
On Mon, 20 May 2019 at 11:49:42 +0200, Lennart Poettering wrote:
> Ideally some infrastructure like PK would supply this mechanism
> instead of us btw.

polkit is for controlled privilege escalation where an unprivileged user
asks a privileged system service to do something, and the system service
asks polkit whether that should be allowed to happen, with possible answers
that include yes, no, or a sudo-like "only if you re-authenticate first".
It also isn't an early-boot service (it needs D-Bus).

Things like prompting for the password for a LUKS volume are really
outside the scope of polkit, but it might make sense for there to be
some lower-level system-wide password prompting concept that can be used
by multiple things that need passwords: systemd, LUKS volume mounting,
polkit agents (the part that implements the "only if you re-authenticate"
policy), gnome-keyring, sudo and so on.

systemd-devel mailing list

Re: [systemd-devel] sd-bus dynamic property table

2019-05-13 Thread Simon McVittie
On Mon, 13 May 2019 at 08:25:03 -0700, Stephen Hemminger wrote:
> The next step is to add ethtool statistics. Each type of network device will 
> have
> different set of named properties.

This is really a D-Bus API design query, not a systemd query.

The standard D-Bus Properties interface is not designed for use
with arbitrary/dynamic named attributes. It's intended to be a D-Bus
equivalent of GObject properties or Qt properties, which are set up
in the object's source code: their values might vary at runtime, but
the list of properties that exists in a class or interface is part of
the API of that class or interface and does not change[1]. Similarly,
D-Bus properties exist in an interface alongside methods and signals,
and an interface either has a Foo property or it doesn't: if it does,
then every object that implements the interface also has a Foo property.

If you need named attributes that vary between objects, I'd suggest
representing them as either a single large property with an a{sv}
as its value, or a D-Bus interface that structurally resembles
Properties but is not Properties (for instance you could call it
com.example.NetworkStatistics, replacing com.example with your reversed
domain name, and have a GetStatistics() -> a{sv} method and optionally
a StatisticsChanged signal).

The org.freedesktop.DBus.Debug.Stats interface in dbus-daemon (it's
compile-time conditional, so your dbus-daemon might not have it)
provides an example of an interface that puts arbitrary attributes
in the result of a method call.


[1] except for maybe backward-compatible feature enhancements where
newer versions introduce more properties
systemd-devel mailing list

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

2019-05-13 Thread Simon McVittie
On Mon, 13 May 2019 at 10:38:38 +0200, Lennart Poettering wrote:
> On So, 12.05.19 13:06, Stanislav Angelovič ( wrote:
> > Quick question: Would it be possible to extend sd-bus to also allow
> > creating messages without requiring a bus?
> This used to be available but we dropped it, since the serialization
> depends on the bus feature set, i.e. wheter fd passing is available,
> and whether gvariant serialization is available.

I think it might make sense to have a way to serialize data to a D-Bus
1.0 message, and/or to a GVariant. I agree that it doesn't make sense
to serialize to an unspecified D-Bus-adjacent binary format, unless you
already know which bus you are talking to, in which case you should use
the most natural format for that bus.

> What's the usecase for using bus message as general marshalling
> storage anyway? Can you elaborate?

Various GLib-related projects like gvdb (used in dconf) and libostree
use GVariant as a stable on-disk encoding for strongly-typed data,
reusing GVariant's D-Bus-inspired type model, in the same sorts of
places that a different project might have used (for example) JSON,
XDR or Protocol Buffers.

Again, this is a reasonable thing to do with data known to be serialized
in GVariant format, or known to be serialized in D-Bus 1.0 format, but
not a reasonable thing to do with a binary format that might be GVariant
or D-Bus 1.0 or some future message encoding.

If what you want is a "variant" type, note that the recursive type
systems of both GVariant and D-Bus 1.0 require out-of-band information
to encode/decode. For both formats, you need to know the type signature
(e.g. "a{sv}") and the byte-order (big- or little-endian), and for
GVariant you additionally need to know the message length in bytes. On
D-Bus this information is already available in the message header, but
if you're using GVariant or D-Bus 1.0 as a standalone serialization you
will need to provide or reinvent a subset of the message header.

systemd-devel mailing list

Re: [systemd-devel] Many user slices created and user managers spawned on boot

2019-01-28 Thread Simon McVittie
On Sat, 26 Jan 2019 at 10:26:23 -0600, Steve Bergman wrote:
> possibly since before the upgrade from Debian 7 with sysvinit to
> Debian 9 with systemd

I hope you upgraded from Debian 7 (usually booted with sysvinit) to Debian 8
(usually booted with systemd), then rebooted, cleaned up any obsolete packages,
and upgraded from Debian 8 to Debian 9 as a separate step. Debian does not
support upgrades that skip a release: our releases are about 2 years apart, and
applying 4 or more years of development to a running system is too much change
to do reliably in one go. If this system is working, it's probably fine now,
but please upgrade in 1-release steps if you upgrade any similar systems.

The major "Debianism" to be aware of with systemd is that in upstream
systemd, logind's [Login] KillUserProcesses option defaults to "yes",
whereas in Debian it defaults to "no".

The benefit of that change is that on Debian systems, tools like screen(1) and
tmux(1) work as intended without needing special steps to exclude them from the
session scope; the cost is that processes that continue to run after a user's
session has ended are not cleaned up (because systemd can't know that they
weren't meant to behave like screen or tmux).

systemd-devel mailing list

Re: [systemd-devel] sd-bus: calling D-Bus method from a D-Bus method callback upon the same D-Bus connection

2019-01-28 Thread Simon McVittie
On Sat, 26 Jan 2019 at 16:22:47 +0100, Lennart Poettering wrote:
> Yes, you may synchronously call into other bus services from an async
> msg hander, but as long as that call runs no incoming msgs besides the
> expected reply will be processed. This means effectively that while
> the synchronous call is running all incoming messages are queued until
> the reply is seen, then the reply is processed and the call returns,
> and only then after you return back into the event loop the queued
> incoming messages are dispatched.
> This also means that while in dbus normally everything is strictly
> ordered, if you do things in this way the reply is "pulled ahead"
> during processing, and the other msgs incoming "pushed back".

For what it's worth, it sounds as though this is the same behaviour as in other
popular D-Bus implementations. In libdbus (the reference implementation) there
is a convention that the functions that behave like this mostly end with
_block, for example dbus_connection_send_message_with_reply_and_block(). In
GDBus (part of GLib) they conventionally end with _sync, for example
g_dbus_connection_call_sync(). In Qt they use mode QDBus::Block. Any advice or
warnings you see about those API families will probably apply equally to the
equivalents in sd-bus.

Reiterating what Lennart said, if you don't use synchronous/blocking calls,
D-Bus messages via the dbus-daemon or a reimplementation like dbus-broker are
usually seen in the same order by everyone on the bus (a mathematician would
say there's a "total order" on the set of messages). If you use
synchronous/blocking calls, you lose that guarantee, because you are processing
some messages out-of-order.

See also (which was written
before the addition of sd-bus and GDBus and the deprecation of dbus-glib, but
is otherwise still relevant).

systemd-devel mailing list

Re: [systemd-devel] Data flow is slow

2018-11-08 Thread Simon McVittie
On Thu, 08 Nov 2018 at 18:57:35 +0530, deepan muthusamy wrote:
> I have two applications. App1 is UI application. App2 is console application.
> Both are communicating through Dbus(session).
> If I start as system service

System services are not part of any session, so they should not attempt
to use the D-Bus session bus.

systemd-devel mailing list

Re: [systemd-devel] [PATCH v2] meson: use the host architecture compiler/linker for src/boot/efi

2018-09-28 Thread Simon McVittie
On Fri, 28 Sep 2018 at 10:40:28 +0200, Lennart Poettering wrote:
> On Do, 27.09.18 17:17, Helmut Grohne ( wrote:
> > cross building systemd to arm64 presently fails, because the build
> > system uses plain gcc and plain ld (build architecture compiler and
> > linker respectively) for building src/boot/efi. These values come from
> > the efi-cc and efi-ld options respectively. It rather should be using
> > host tools here.
> > 
> > Fixes: b710072da441 ("add support for building efi modules")
> Hmm, any chance you could submit this through github please?

This is an updated version for
 which is owned by mbiebl
(presumably Helmut isn't sending his own pull requests for whatever

systemd-devel mailing list

Re: [systemd-devel] non-dev systemd-devel package for Linux

2018-08-31 Thread Simon McVittie
On Fri, 31 Aug 2018 at 10:52:30 -0700, Sayeed hyder wrote:
> Thanks Silvio. Unfortunately, I cannot use devel. IIUC, rhel/centos does not
> provide a non-dev systemd package? That does not sound right.

Are you mixing up the concept of an unstable version that is still under
development, and the concept of a package containing development headers
to be used to compile your own software? They both have the word
"development" in, but the thing that is being developed is different.

The -devel packages in Red Hat-derived distributions and the -dev
packages in Debian-derived distributions are equivalent. They both
contain the header files, static libraries, etc. that are needed if you
are developing your own software against a library.

The -devel and -dev suffixes do not indicate that the software in those
packages is not recommended for use. They are of the same quality and
stability as any other package built from the same version of the same
source code.

(Packages that contain software that is not yet recommended for
use, but is packaged anyway, are a lot rarer, because people don't
normally package software in a stable distribution until the software
is also stable. Examples of "not ready yet" software in Debian include
wine-development and llvm-snapshot.)

systemd-devel mailing list

Re: [systemd-devel] Select on value of log message

2018-08-30 Thread Simon McVittie
On Thu, 30 Aug 2018 at 12:48:02 +0200, Cecil Westerhof wrote:
> Posted the problem in a Debian newsgroup.

Please send all Debian-specific bug reports and feature requests to its bug
tracking system , filed against the package
that has the bug or is missing the feature. It's a big project, and posts
in other venues (newsgroups, mailing lists, IRC channels, forums, bathroom
walls, etc.) are likely to get lost, or not be read by the right people who
would do the work.

systemd-devel mailing list

Re: [systemd-devel] Returning a struct from an sd-bus method

2018-08-23 Thread Simon McVittie
On Thu, 23 Aug 2018 at 17:34:14 +0100, Simon McVittie wrote:
> Finally, I think the message-building API expects struct members as
> individual arguments, like
> sd_bus_reply_method_return(m, "xx", (int64_t) s->x, (int64_t) s->y);

Sorry, obviously that's correct when not using a struct. What I meant is
that I think this:

sd_bus_reply_method_return(m, "(xx)", (int64_t) s->x, (int64_t) s->y);

might be the correct way to return a message containing a single struct.

systemd-devel mailing list

Re: [systemd-devel] Returning a struct from an sd-bus method

2018-08-23 Thread Simon McVittie
On Thu, 23 Aug 2018 at 16:52:38 +0200, Niall Murphy wrote:
> struct pack {
>     int x;
>     int y;
> };
>     return sd_bus_reply_method_return(m, "(xx)", s);

Is there a reason why you're returning a struct/tuple? D-Bus methods
can return as many things as you want[1], unlike C functions, so a more
conventional return type would be "xx" instead of "(xx)".

You also have a mismatch between your integer types: "x" is a 64-bit signed
integer (mnemonic: the 64-bit signed and unsigned types are "x" and "t",
which are the first letters of "sixty" that weren't already used for
something more important) so they'll expect an int64_t. The type
signatures for 32-bit integers are "i" and "u", depending on signedness.
There is no correct type signature for types like int/long/long long
whose size can vary between platform: integers in D-Bus messages are
always fixed-size.

Finally, I think the message-building API expects struct members as
individual arguments, like

sd_bus_reply_method_return(m, "xx", (int64_t) s->x, (int64_t) s->y);

although I could be wrong about that.


[1] up to arbitrary message size limits measured in megabytes
systemd-devel mailing list

Re: [systemd-devel] Restarting a service as user instead as root

2018-08-13 Thread Simon McVittie
On Mon, 13 Aug 2018 at 12:44:48 +0200, Cecil Westerhof wrote:
> I tried to put this in:
>     /etc/polkit-1/rules.d/10-auth.rules
> I am using Debian 9.

Debian uses an old version of polkit (with most of the changes from
newer versions backported) due to maintainability concerns about the
use of Javascript as the policy language in newer versions. Simpler
rules can be expressed in the old "local authority" policy language
(see the man pages installed with polkit on your Debian system) but
finer-grained rules using lookup() cannot be translated for Debian's
older polkit version.

systemd-devel mailing list

Re: [systemd-devel] How to build only udev

2018-07-04 Thread Simon McVittie
On Wed, 04 Jul 2018 at 11:36:23 -0700, Kevin Greene wrote:
> 2018-07-03 18:18 GMT-07:00 Mike Gilbert :
> Why not just install the libudev-dev package on a Ubuntu dev
> system/chroot? That would be much simpler than building libudev from
> scratch, and would ensure you build against the actual library Ubuntu
> uses.
> I appreciate the suggestion. I would definitely much prefer to do that, but
> I'm cross-compiling, and there doesn't appear to be a way to install arm64
> libudev-dev on x86_64

You can add arm64 as a "foreign architecture" and install the arm64
libudev-dev that way, in a chroot/container that is based on the same
release of Ubuntu as your target platform, but amd64 (x86_64) instead
of arm64:

sudo dpkg --add-architecture arm64
sudo apt-get update
sudo apt-get install libudev-dev:arm64

(Depending on the Ubuntu release of interest, you might also be able
to install an entire cross-toolchain by installing
crossbuild-essential-arm64 in the same chroot/container.)

See also
(that's Debian armhf not Ubuntu arm64, but the principle is the same).

systemd-devel mailing list

Re: [systemd-devel] Authenticating "sd bus" fails with Invalid argument

2018-06-19 Thread Simon McVittie
On Tue, 19 Jun 2018 at 12:32:19 +, wrote:
> The system is on a quite old kernel (3.18.44)
> At this point, things go wrong when
> recvmsg() is called on bus->input_fd with flags MSG_DONTWAIT|MSG_NOSIGNAL|
> MSG_CMSG_CLOEXEC. This syscall returns -22 (Invalid argument) which propagates
> all the way up to the user.

(I hate the way kernel/syscall/libc error-reporting isn't accompanied
by a human-readable message that could tell you *which* argument is
invalid... compare with GLib/D-Bus errors)

MSG_NOSIGNAL is meaningless for recvmsg()
 so it's possible
that your older kernel doesn't allow it, but newer kernels allow and
ignore it? sd-bus should probably only use that flag for sendmsg()
and the rest of the send(2) family.

systemd-devel mailing list

Re: [systemd-devel] DynamicUsers and read-only /var

2018-05-16 Thread Simon McVittie
On Wed, 16 May 2018 at 16:33:08 +0200, Antoine Pietri wrote:
> On Wed, May 16 at 13:05 PM, Jérémy Rosen  wrote:
> > hmm, I think you could have the whole /var as a tmpfs and use
> > systemd-tmpfiles (man:tmpfiles.d) to initialize /var at startup by
> > copying some template directory from a read-only location (typicalli in
> > /usr)
> That's another interesting workaround, but ideally we'd like to let
> all the packages install stuff in /var/lib like they would normally,
> and only put some tmpfs in /var after that.

The purpose of /var is that it contains variable data, so a read-only
/var seems like a rather contradictory goal?

I think you'd really be better off redirecting the packaged
or package-manager-produced contents of /var to /usr/var or
/usr/share/factory/var or something (perhaps using your package manager's
equivalent of dpkg-divert if it has one), and using systemd-tmpfiles to
populate a tmpfs with copies or symbolic links (or possibly bind-mounting
selected directories from the read-only copy, if entire subtrees like
/var/lib/dpkg are read-only except during package manager operations).

Projects like libostree and rpm-ostree might have some useful concepts
or code for managing immutable, read-only rootfs or /usr deployments,
since that's what they do: in an ostree-based OS, /usr is an
atomically-updated immutable tree, directories like /var and /home are
locally-maintained, and /etc is a three-way merge between the old
/usr/etc, the new /usr/etc and the local /etc.


systemd-devel mailing list

Re: [systemd-devel] how to make systemd ignore the memory cgroup controller and hierarchy

2018-05-09 Thread Simon McVittie
On Wed, 09 May 2018 at 16:46:09 +, john terragon wrote:
> I have the memory cgroup controller configured in the kernel. I want to use it
> myself directly without interference from systemd.

I don't think this is supported. systemd behaves as though cgroups v2 is
in use (single unified cgroup hierarchy) even if you are currently using
cgroups v1 (one parallel hierarchy per controller).

systemd-devel mailing list

Re: [systemd-devel] How to change XDG_RUNTIME_DIR permissions

2018-04-09 Thread Simon McVittie
On Mon, 09 Apr 2018 at 17:27:10 +, john terragon wrote:
> created by the logind service.I want to make the socket of the pulseaudio
> server of one particular user available to all the others.

This is basically PulseAudio system-wide mode:

... except worse, because instead of potentially being able to escalate
privileges to a dedicated system uid that runs the PulseAudio system
server, you can potentially escalate privileges to the account of
another user.

I would suggest using the system-wide mode instead: it's a bad idea
for all the reasons listed in the link above, but seems less bad than
reinventing it via a user's account.

systemd-devel mailing list

Re: [systemd-devel] how to login into a container booting with a minimal 'debian distro unstable' via nspawn

2018-03-26 Thread Simon McVittie
On Sun, 25 Mar 2018 at 19:50:24 +0300, Mantas Mikulėnas wrote:
> Does debootstrap actually create a passwordless root account?

No, it creates a system with all system accounts locked[1] (including
root, daemon, bin, www-data, etc.) and no non-system accounts. There is
no single correct answer for how a Debian system's users should be set
up, so debootstrap defers the decision to you.

If you want to log in via a getty (as opposed to just running commands
inside the chroot/container without booting it, which is perhaps a
more common use of debootstrap), then you will have to set or clear the
root account's password or create a non-root account.

In recent versions, a truly minimal Debian chroot/container (debootstrap
--variant=minbase) doesn't have an init system like systemd or sysvinit,
so it *can't* be booted in the normal way. The larger "standard system"
produced by debootstrap without --variant includes all packages with
Priority >= standard, including systemd for modern releases or sysvinit
for old releases, and can be booted.


$ zcat minbase.tar.gz | tar -xO ./etc/passwd | grep root
$ zcat minbase.tar.gz | tar -xO ./etc/shadow | grep root
systemd-devel mailing list

Re: [systemd-devel] Starting a service at shutdown time, with requirements

2018-03-20 Thread Simon McVittie
On Tue, 20 Mar 2018 at 19:16:59 +, Mantas Mikulėnas wrote:
> On Tue, Mar 20, 2018, 21:09 Colin Walters  wrote:
> Another way I've thought about handling this is to basically invert things
> so that
> we have a "stub" unit that starts on bootup, and its ExecStop does the 
> real
> work
> Currently this is the recommended method; it's a little ugly indeed but fits
> quite well into the shutdown process. Recent systemd versions should let you
> skip the dummy ExecStart.

The unattended-upgrades tool on Debian/Ubuntu works like this when
configured to install updates during shutdown (the same idea as systemd's
"reboot to a special mode, install updates, reboot again", but with fewer
reboots). I can confirm that in recent-ish systemd (v232 in Debian 9,
although not the older v215 in Debian 8) the ExecStart is unnecessary.

systemd-devel mailing list

[systemd-devel] Should long-running child processes clear INVOCATION_ID?

2018-03-02 Thread Simon McVittie
When dbus-daemon carries out a mixture of systemd and traditional
(non-systemd) activation, we get a process tree like this:

systemd --user   (init.scope)
|- dbus-daemon --session (dbus.service)
|  |- (babysitter process)
|  |  \- gnome-shell-calendar-server [t]
|  \- (babysitter process)
| \- dleyna-renderer-service [t]
|- gnome-terminal-server (g-t-s.service) [s]
\- xdg-document-portal   (x-d-p.service) [s]

[s]: systemd activation; [t]: traditional activation

or the equivalent for the system bus.

As of current git master, the dbus-daemon removes some of its environment
variables from the environment passed to traditional D-Bus services
like gnome-shell-calendar-server, because they are applicable to to the
dbus-daemon but not the child. In particular JOURNAL_STREAM, LISTEN_*
and NOTIFY_SOCKET get this treatment.

However, it wasn't clear to me what this code should do with the
INVOCATION_ID. Would it be better (less misleading) to say that
gnome-shell-calendar-server is part of the same INVOCATION_ID as its
dbus-daemon parent, or to say that it has no invocation ID?

systemd-devel mailing list

Re: [systemd-devel] Why is systemd-run --scope synchronous?

2018-02-06 Thread Simon McVittie
On Tue, 06 Feb 2018 at 13:09:26 +0100, worz wrote:
> I am not sure why things are different. I also
> notice the difference is that in case of --scope, the service manager is
> not really the parent process, and it's just that systemd-run creates a 
> transient scope and places the process inside it, which is ok, but not sure
> why it is different than running it as a service, or even running the process
> in the scope unit as a child of the service manager.

If I understand correctly, that's exactly the purpose of scope units:
they allow processes that are not a child of the service manager to be
made visible to the service manager as a unit.

For instance, when Flatpak is run on a system with `systemd --user`,
it puts each instance of a Flatpak app in a scope, even though those
processes need to be children of the Flatpak process so they can inherit
various fds and environment variables from it.

(One notable example of a fd that might be inherited by child processes
is "the controlling terminal".)

systemd-devel mailing list

Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2018-01-23 Thread Simon McVittie
On Tue, 23 Jan 2018 at 15:47:21 +0100, Franck Bui wrote:
> Basically, systemd mounts all filesystems listed in /etc/fstab (unless
> "noauto" is used) which is good since that's how fstab was used when
> SysV was the init system.
> However it also introduced another "feature" which basically
> automagically mounts a filesystem (listed in fstab) every time its
> backend device re-appears.

Am I right in thinking this is only done if the filesystem is not declared
as noauto in fstab?

If you don't want systemd to do its best to ensure that a particular
filesystem is always mounted, please add the noauto option to it. In the
absence of noauto, consumers of fstab (including udev and systemd) assume
that you want this filesystem mounted at all times (between early startup
and late shutdown), and will get as close to that as is achievable.

> [fstab] has never been the place used by disk managers to list
> mount-points that should be automatically mounted after the system
> booted

That's not true, some dynamic disk managers outside systemd (at least
udisks) do respect configuration in fstab.

> I'm not sure why the old behavior is not compatible with modern
> storage

The traditional behaviour requires you to have a well-defined point during
boot at which you know that all hardware that was attached at power-on has
been detected, and all hardware that subsequently appears was hot-plugged
and should go through a different code path; but with modern buses
(most visibly USB, but also buses that you probably think of as more
static than they really are), there is no time at which you can know
that all hardware that was attached at power-on has now been detected.

It would be possible to use an arbitrary timeout, but arbitrary timeouts
are a problematic design: either they're too short and they unpredictably
miss some initially-attached hardware, or they're too long and they
arbitrarily slow down everyone's boot process, or (more likely) both
failure modes at the same time for different people.

systemd-devel mailing list

Re: [systemd-devel] sd_watchdog_enabled: how to use when forking process?

2018-01-19 Thread Simon McVittie
On Fri, 19 Jan 2018 at 17:22:51 +, philip is hungry wrote:
> however if i run the forkme function (to put process in the background) it
> behaves as follows:
> Jan 18 15:06:25 thinkpad waitonly[11228]: Return from forkme = 11228
> Jan 18 15:06:25 thinkpad waitonly[11228]: Return from lockme = 0
> Jan 18 15:06:25 thinkpad waitonly[11228]: PID to compare with watchdog_pid:
> 11228

systemd tells your service which process it expects to be sending
keepalives ($WATCHDOG_PID), and only accepts keepalives from that
process. The forked child process has some other process ID, so
sd_watchdog_enabled() returns false for it.

If you want to use the watchdog, don't fork and go to the background: it's
unnecessary for systemd services. To notify systemd that your process
is ready to receive requests (which was done via the double-fork trick
in init-script-based init systems), a daemon that natively supports
systemd features can use sd_notify() and Type=notify.

If you want your service to continue to support non-systemd init systems,
you might want to add a --no-fork command-line option and make the systemd
unit's ExecStart use that option. For example, that's how it works for
dbus-daemon, which needs to continue to default to forking for
compatibility with what it does on non-Linux OSs or non-systemd init.
Or, if your service will only ever run under systemd, you can make it
not fork/background itself at all.

systemd-devel mailing list

Re: [systemd-devel] systemctl start second.service first.service

2018-01-12 Thread Simon McVittie
On Thu, 11 Jan 2018 at 21:41:54 +0100, Reindl Harald wrote:
> come on - nobody cares about this bullshit bingo about what are jobs, units
> and services

Please try to be polite when you are in a situation where you could be
perceived as representing a community. Responses like this to discussion
of a technical issue do not help systemd's reputation, and using jargon
terms precisely is a useful way to describe how code works.

For what it's worth, I think I agree with the technical point you were
making, which (if I understand correctly) is that it would be better for
each "systemctl start" invocation to create a single transaction (job)
that will start all the units named on the command-line in an order
chosen by the systemd manager to respect their Before/After ordering.

systemd-devel mailing list

Re: [systemd-devel] Dependencies on DBus activated services during shutdown

2018-01-08 Thread Simon McVittie
On Mon, 08 Jan 2018 at 16:07:48 +0100, Michal Koutný wrote:
> As it comes, A.service needs B.service for proper termination. During
> the shutdown transaction there is unspecified ordering of the two (since
> the dependency is implicit only) and B.service is stopped before A.service.

Does A.service even need B.service during shutdown if it has not
previously interacted with (=> started) B.service?

Or is the issue that B.service handles requests from A.service, then shuts
down when unused (leaving "background" state that it's responsible for),
and during shutdown, A.service needs to wake B.service back up to undo
those requests?

> I know this could be circumvented by explicitly specifying
> After=b.service for the A.service

To be honest that doesn't seem too bad to me.

On Mon, 08 Jan 2018 at 16:53:04 +0100, Jérémy Rosen wrote:
> That means that the only way to fix that without explicitely telling someone
> about the dependency is to allow dbus to start units while its shutdown is
> pending [...] this seems to be explicitely forbidden

I didn't write that special case, but I agree with it. Starting D-Bus
services while the sword of Damocles is hanging over dbus-daemon's
head does not sound like a route to guaranteed success. As soon as
dbus-daemon gets SIGTERM, they'll find that their D-Bus AF_UNIX socket
is rather less useful than it was a moment ago...

If A.service can be made to shut down correctly without B.service,
then that seems good in any case. (What happens if B.service crashes?)

Failing that, if A.service genuinely needs D-Bus during its shutdown,
it probably also makes sense to serialize it After=dbus.service (not
just dbus.socket) so that dbus-daemon will be kept alive until A.service
actually exits.

If systemd had an asymmetric StopBefore=dbus.service, that could be used
here (and also for );
but it doesn't (and I can see why the systemd maintainers want to preserve
the symmetry of startup/shutdown order), and After=dbus.service is
the next best thing. I agree with Lennart's assertion on that bug that
having ExecStop pretend to stop dbus-daemon, but not actually do it,
is the wrong answer.

systemd-devel mailing list

Re: [systemd-devel] proper use of /run/{user/, }/systemd/private sockets

2017-11-14 Thread Simon McVittie
On Tue, 14 Nov 2017 at 09:19:08 +0100, Jérémy Rosen wrote:
> That being said, the system socket location is hardcoded not just in systemd,
> but in the dbus specification itself.

The D-Bus Specification does not say anything about the
.../systemd/private sockets. That would be inappropriate: those sockets
are private (not API), and are part of systemd (not D-Bus).

The socket path that is hard-coded in the D-Bus specification is the
well-known system bus socket, /var/run/dbus/system_bus_socket, used by
`dbus-daemon --system` and all D-Bus client implementations (dbus, GDBus,
sd-bus and others). This is present in the D-Bus Specification because
every D-Bus implementation needs to agree on it: otherwise they cannot

If you have dbus-daemon installed and available, then you can
communicate with the system instance of systemd (pid 1) via the D-Bus
system bus. This is a public API that offers the same functionality as
/run/systemd/private, except that it does not work without the system

Similarly, if you have dbus-daemon installed and available and dbus was
configured with the --enable-user-session option (or on Debian derivatives
and similar, if the dbus-user-session package is installed), then you
can communicate with the per-user instance of systemd (systemd --user)
via the D-Bus session bus (which is a "user bus" in this configuration),
$XDG_RUNTIME_DIR/bus. This is a public API that offers the same
functionality as $XDG_RUNTIME_DIR/systemd/private, except that it does
not work without the per-user dbus-daemon.

(Or strictly speaking, you don't *need* dbus-daemon; you could be using
a compatible reimplementation instead.)

systemd-devel mailing list

Re: [systemd-devel] How to give users permissions to /dev/kfd

2017-10-16 Thread Simon McVittie
On Sat, 14 Oct 2017 at 17:50:33 +0300, Mantas Mikulėnas wrote:
> No, it's only available for local sessions (ones which systemd-logind 
> considers
> "local" + "active"). I think the idea is that console users automatically get
> more privileges in general.

Specifically, the idea is that console users should have access to
devices that are the machine representation of things they can physically
access anyway. The classic example is audio. If Alice is sitting at a
desktop/laptop computer and Bob is ssh'd in to the same computer, it's
fine for Alice to be able to record the same audio that she can hear
already; but it is usually not OK for Bob to be able to record audio
because that would let him spy on Alice.

Similarly, logind defaults to allowing local active users to shut down
the machine (because they are likely to be in a position to pull the
plug or remove the battery anyway), but not remote users (to prevent
them from causing denial-of-service for local users or other remote users).

> For SSH-only usage, use traditional groups (e.g. add yourself to the "video"
> group). To assign group ownership to /dev/kfd, use GROUP="foo" in udev rules.

And, yes, the way to bypass the "only local users" bit is to add your uid
to an appropriate group, which is a way of saying: this user has special
privileges, and can access something (in your case video) even when not
physically present.

systemd-devel mailing list

Re: [systemd-devel] start user-service only with UID greater than 1000

2017-07-25 Thread Simon McVittie
On Wed, 26 Jul 2017 at 00:02:06 +0200, Jakob Schürz wrote:
> I have no idea, why this users get a PAM-Session.
> Now i can see there is also a systemd --user process for
> debian-security-support:
> Jul 25 23:54:49 aldebaran systemd[1]: Starting User Manager for UID 137...
> Jul 25 23:54:49 aldebaran systemd[6366]: pam_unix(systemd-user:session):
> session opened for user debian-security-support by (uid=0)

it looks as though that package is using su. It should probably be using

runuser -u "$USERNAME" /bin/bash -c "..."

instead, because whatever the question is, su is usually the wrong answer.

Presumably the other daemons you mentioned are also using su in a cron job
or maintainer script or something.

On my Debian system, /etc/pam.d/su pulls in /etc/pam.d/common-session,
which uses pam_systemd; but /etc/pam.d/runuser does not. So anything that
calls su will get a login session, with the side effect of a `systemd --user`,
but anything that calls runuser will not get a login session and a
`systemd --user`.

systemd-devel mailing list

Re: [systemd-devel] no user dbus session in container

2017-07-19 Thread Simon McVittie
On Wed, 19 Jul 2017 at 09:31:36 +, arnaud gaboury wrote:
> Do I really need a per user dbsu session in my container?

I don't know. Do you? You haven't said anything about how you start the
container, how you log in to the container, what its purpose is, or how
(if at all) its purpose interacts with the session bus.

Again, the only advice I can give you based on the information you
provided is to read the system log and look for error messages.

If you believe you have found a bug in some component (systemd or dbus
or your container manager), the first step in resolving that bug is
to describe in detail how the bug can be reproduced, including all the
steps taken and any error messages that result from them.

Since the trigger for this regression was a Fedora upgrade, Fedora support
channels might be a more useful source of help and information than the
systemd upstream mailing list (but I suspect the first things they will
ask you to do are to describe the steps to reproduce the issue and check
the system log, so you might as well do those first, and include them
in your request for help).

systemd-devel mailing list

Re: [systemd-devel] no user dbus session in container

2017-07-18 Thread Simon McVittie
On Fri, 14 Jul 2017 at 12:36:12 +, arnaud gaboury wrote:
> After upgrade from Fedora 25 to 26, there is no more user dbus session for 
> user
> in container.
> On container, user can't connect to dbus session, and I have no idea why.
> May someone please give me some hints on how to debug this issue?

Please start by reading the system log (the Journal).

The chain of events that is meant to result in a D-Bus session bus is:

* A user logging in (somehow) starts a login session
* The login session starts an instance of `systemd --user`
* `systemd --user` starts the dbus.socket user service, listening on
  that user's $XDG_RUNTIME_DIR/bus
* Some client in the login session interacts with the session bus
* As a side-effect of connecting to $XDG_RUNTIME_DIR/bus,
  `systemd --user` starts the dbus.service user service
  (dbus-daemon --session --address=systemd:)
* The dbus-daemon accepts the client's connection

The system log should tell you which step in that chain of events is
no longer happening.

systemd-devel mailing list

Re: [systemd-devel] Is there a reason to run systemd Units with root access?

2017-07-06 Thread Simon McVittie
On Tue, 04 Jul 2017 at 20:33:54 +, Mariusz Wojcik wrote:
> As far as I know, there
> aren’t many services that need full root access (maybe for getting a low port
> number).

systemd system units are basically a replacement for LSB (or sysvinit
if you prefer) init scripts, which always run as full root, and can drop
privileges themselves if they want to.

Anything that runs with capabilities that trivially allow escalation to
CAP_SYS_PTRACE) might as well be full root. Such processes are in the
trusted computing base (TCB): it would be within their technical ability
to break security policies.

Using an unscientific sample consisting of the 12 system services starting
with "a" or "b" on my Debian laptop:

* apt-cacher-ng has a non-trivial User (systemd starts it unprivileged)
* avahi-daemon starts as root to do some privileged setup, then drops
  privileges itself (this is a common pattern, dbus-daemon does this too)
* alsa-{restore,state} don't necessarily need to be root, but do need
  hardware access, are not persistent (they are "oneshot" services run
  during boot and shutdown), and they are so simple that giving them
  privilege separation seems like a poor use of anyone's time
* bluez runs as root but drops most capabilities
* the rest run as "full" root and are in the TCB, and seem like they
  legitimately need it (for example atd and anacron have it as part of
  their "API" that they can be used to run arbitrary tasks, including
  being full root)

I personally think the syntactic/semantic validity distinction here
is not the least-astonishment behaviour, and my preferred resolution
for this issue would be for User=7up or User="this name is silly!" to
be exactly equivalent to specifying a User with a "normal" name that
happens to be missing from `getent passwd` (in other words, the unit
fails to start with exit status 217/USER). But you can tell I don't
think this is critically important by the fact that I haven't written
and proposed a patch with that behaviour. If this is more important to
you than it is to me, a reasonable next step would be to put together
that patch.

systemd-devel mailing list

Re: [systemd-devel] [RFC] AddMatch on a private/direct bus

2017-06-09 Thread Simon McVittie
On Fri, 09 Jun 2017 at 15:20:49 +0200, Łukasz Stelmach wrote:
> We are developing a daemon that is monitoring a system. One of its
> sources of information is systemd. To avoid dependency on dbus-daemon
> (which may fail and cripple our daemon) the daemon connects to
> /run/systemd/private to listen to signals emitted by systemd. However,
> we don't need all signals, only a few. Thus we are going to create code
> which will filter and dispatch signals.

> We think the best place for such code is not our daemon but rather
> sd-bus. Our question is: would you accept the patch adding a signal
> filter/dispatcher for direct DBus connections? Do you have any
> recommendation for such functionality

Please don't call it a private *bus* unless it implements the full API of
the dbus-daemon, or at least something the same "shape" as that. D-Bus
terminology makes a distinction between connections to a server (one or
more clients connect to one server, which processes messages itself) and
to a bus (clients connect to a server/broker/hub in the middle of a star
topology, the "message bus", and the message bus in the middle forwards
messages between clients and implements the standard org.freedesktop.DBus
APIs, including signal subscriptions and name ownership). As far as I'm
aware, /run/systemd/private is not a bus in those terms: clients that
connect to it can talk directly to systemd, but cannot talk to each
other. A private or direct D-Bus *connection* seems a better term.

The device nodes in kdbus were effectively buses, although using
ioctls instead of the org.freedesktop.DBus interface - they delivered
messages between clients, mediated name ownership and so on. I don't
think kdbus had an equivalent of private/direct D-Bus connections.

Receiving signals on a private/direct connection with the equivalent
of g_dbus_connection_signal_subscribe() seems like a reasonable thing
for sd-bus to have, if its maintainers want that. I think GDBus'
g_dbus_connection_signal_subscribe() works fine on private/direct
connections if you pass in G_DBUS_SIGNAL_FLAGS_NO_MATCH_RULE.

However, are you also proposing writing a reimplementation of
the dbus-daemon's signal subscription matching as configured
by AddMatch(), and running it on the service side, so
in this case in systemd? Or are you confusing client-side
subscription (e.g.  g_dbus_connection_signal_subscribe() with
G_DBUS_SIGNAL_FLAGS_NO_MATCH_RULE) with bus-side filtering (adding
match rules)?

If you are considering reimplementing signal subscription, I would
recommend first benchmarking the most naive possible implementation (a
connection is either subscribed to all signals from systemd or no signals,
and ignores the unwanted ones client-side). I suspect you might find that
doing the filtering client-side is not a performance problem in practice;
depending how optimal the server-side filtering implementation is,
server-side filtering might even end up more "expensive" than just
delivering everything and requiring clients to cope, because D-Bus
signal subscription is a lot more general-purpose than what would
be useful to you in this situation in practice.

If you do find that you need server-side filtering, I think I'd prefer it
if you used a non-standard interface name for your signal subscription
mechanism (so org.freedesktop.systemd1.Manager.AddMatch() or something
rather than org.freedesktop.DBus.AddMatch()), although clearly you're
welcome to use the same syntax for subscriptions that AddMatch uses.
I would prefer not to cloud the distinction between connections and
buses by implementing subsets of the org.freedesktop.DBus interface on
non-buses: each connection should either be direct, or a full bus.

A much simpler subscription language (some sort of middle ground between
the simplicity of o.fd.systemd1.Manager.Subscribe() and the complexity
of o.fd.DBus.AddMatch()) might be another option.

systemd-devel mailing list

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

2017-04-25 Thread 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.

systemd-devel mailing list

Re: [systemd-devel] sd-bus connections & authentication timeout

2017-03-23 Thread Simon McVittie
On Mon, 20 Mar 2017 at 19:40:04 +0100, Stanislav Angelovič wrote:
> Regarding polling, I understand, but I fear this way we could get race
> condition on the connection instance, since we'd have a thread doing the
> polling and processing in a loop on the connection, and some other thread (say
> handling the UI, or an external system event, or incoming DBus call from
> another connection or whatever else) issuing a DBus call on the same
> connection.

Don't do this. The sd-bus connection is not designed to be safe to
access from multiple threads.

If you need thread-safe D-Bus, then you will need a design where one thread
"dispatches" the D-Bus connection (with sd-event or the GLib
main loop or whatever abstraction around epoll/poll/select you prefer),
and all other threads submit requests to it and get events back from it.
This is essentially what GLib's GDBus does - all the public APIs just
submit requests to a worker thread that is not directly accessible by
user code.

libdbus (the reference implementation of D-Bus) did try to support the
situation you are concerned about, but doing that turns out to be basically
unmaintainable; we've fixed the worst issues, but it has never been very
reliable, and we strongly recommend not doing it. For best results, choose
either always-threaded (GDBus' design) or never-threaded (sd-bus' design,
and also the recommended pattern for libdbus for the last few years)
and stick to it.

> This involves asynchronous programming paradigm for quite a simple
> thing, IMHO.

D-Bus is fundamentally an asynchronous message-passing system, in the
same sorts of ways that X11, Wayland and most network protocols are.
If asynchronous message passing is not acceptable to you, then D-Bus is
probably not going to be the right solution to your requirements.

If you stop reading from your D-Bus socket, the dbus-daemon will
eventually have to disconnect you, because it cannot distinguish
between that and a denial of service attack. The timeout that you
encountered is precisely there to stop malicious processes from carrying
out a denial of service attack on the system dbus-daemon instance
by tying up all of its file descriptors with unauthenticated connections,
and there are similar limits to stop a malicious process from carrying
out a DoS attack on the system dbus-daemon instance by making it
consume unbounded amounts of memory.

In general we put these arbitrary limits in for good reasons, not
just to make your life difficult :-) In this case the relevant
security vulnerability was CVE-2014-3639.

systemd-devel mailing list

Re: [systemd-devel] suspend hook as user service

2017-02-20 Thread Simon McVittie
On Fri, 17 Feb 2017 at 19:41:00 +0100, Michael Hirmke wrote:
> A much better approach is to write a script or program listening for the
> according signals "PrepareForSleep" and "PrepareForShutdown" on the dbus
> interface "org.freedesktop.login1".

This is the thing to do. It allows your program to delay suspend until
it is ready for suspend to happen, or prevent suspend altogether.

For instance, Telepathy delays suspend so it can try to take instant
messaging connections offline first:

systemd-devel mailing list

Re: [systemd-devel] General question about dbus-activatable services

2017-02-16 Thread Simon McVittie
On Thu, 16 Feb 2017 at 02:01:29 +0100, Christian Rebischke wrote:
> I would like to start
> ibus-daemon automatically on login in my user session.
> But it was rejected, due to the fact that a dbus-activatable service for
> ibus exists.

If there is a D-Bus service already, the way to get it started
by `systemd --user` is to link the two together, something like this:

Having duplication between D-Bus session services and systemd user
services without linking them together with `SystemdService` is likely
to be harmful (it'll get started twice under at least some circumstances).

As a side-effect, doing something similar to that xdg-desktop-portal-gtk
PR will give you a service that you can enable using a symbolic link in

I've commented on the ibus bug.

systemd-devel mailing list

Re: [systemd-devel] WebUSB

2017-01-16 Thread Simon McVittie
On Mon, 09 Jan 2017 at 10:20:33 +0100, Lars Knudsen wrote:
> 2. make sure that webusb devices will be somehow accessible to be used by a
> browser running with user permissions (current temp solution listed here:
> adding user to plugdev, adding 0664 permissions to device: https://
> )  
> (udev/systemd task).

Since I didn't see a response to this: this sounds like a job for uaccess.
Most things that happened via the plugdev group (on Debian/derivatives)
5 or 10 years ago should happen via uaccess now.

TAG+="uaccess" in a udev rule results in an ACL being set so that
a currently-active logind session on the same seat can read and write
the device node.

systemd-devel mailing list

Re: [systemd-devel] User bus broke automatic multiseat

2017-01-16 Thread Simon McVittie
On Wed, 14 Dec 2016 at 23:23:55 +0300, Oleg Samarin wrote:
> The following change in systemd-226:
> systemd now supports the concept of user buses replacing
> session buses, if used with dbus-1.10 (and enabled via dbus
> --enable-user-session). It previously only supported this on
> kdbus-enabled systems, and this release expands this to
> 'dbus-daemon' systems
> totally broke the automatic multiseat with GDM: https://bugzilla.redhat
> .com/show_bug.cgi?id=1404849
> What configuration options can restore the the old session-bus
> behavior?

Either don't configure dbus with --enable-user-session, or teach gdm
to create a per-display D-Bus bus for each of its X11 displays (or
Wayland equivalent).

For the former solution, see the split between the dbus and
dbus-user-session packages in Debian. dbus is always configured
with --enable-user-session there, but we split out the user-session parts
(basically /usr/lib/systemd/user) into dbus-user-session_*.deb so that
it's opt-in.

For the latter solution, the patch/script on the Red Hat bug you referenced
are implementations of the right sort of idea. Please talk to the gdm (GNOME)
developers about the best way to integrate that.

systemd-devel mailing list

Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

2017-01-16 Thread Simon McVittie
On Sat, 03 Dec 2016 at 11:18:43 +0530, MohanR wrote:
> I'm looking through this --enable-user-session in dbus-daemon. Even if
> I enable that option, how can I retrive uniq DBUS_SESSION_BUS_ADDRESS
> from systemd started dbus-daemon to pass it to gnome-session?

I suggest taking a look at how it has been done in an OS distribution that
integrates --enable-user-session, such as Debian (with the dbus-user-session
package), Fedora or Arch Linux.

The socket used for the systemd-started dbus-daemon is predictable per-uid,
and recent versions of the major D-Bus implementations (libdbus, GDBus,
sd-bus) all try that socket before autostarting a new one.

Setting DBUS_SESSION_BUS_ADDRESS is only necessary to be nice to minor
D-Bus implementations (ndesk-dbus, dbus-java, etc.) or programs that
second-guess how D-Bus works (which currently includes gnome-session,

systemd-devel mailing list

Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

2016-12-02 Thread Simon McVittie
On Fri, 02 Dec 2016 at 13:58:01 +0530, Mohan R wrote:
> Let say if a user already have a session(session0) in a seat (customseat0) and
> he want to start another session in another seat (customseat1).

Does this mean your user is trying to be physically present in two places
at the same time? How is this a useful thing to do? :-)

> Is there any way to make pam_systemd provides uniq DBUS_SESSION_BUS_ADDRESS 
> for
> every session (may be unix:path=$XDG_RUNTIME_DIR/$XDG_SESSION_ID/bus)? or is
> there any way to ask 'systemd --user' to provide different

More background on user-sessions in general:

pam_systemd does not do this unless you have configured dbus-daemon
to provide one bus per logind user-session
(./configure --enable-user-session), which is not the default.
Either you or your OS vendor have explicitly chosen this model: if that
doesn't match your requirements, you need to revert this choice.

If you require multiple D-Bus sessions per logind user-session, you must
either configure dbus without --enable-user-session (the default is
equivalent to --disable-user-session), or mask or remove the
dbus.service and dbus.socket systemd user units that are installed
by enabling that option (/usr/lib/systemd/dbus.*).

The user-session support in dbus is designed to be easy to enable or
disable by adding/removing packages, if your OS vendor packages it
suitably. For example, in Debian (including derivatives like Ubuntu),
/usr/lib/systemd/dbus.* are packaged separately in the dbus-user-session
package, so you can remove that package to go back to the older model.

If your OS vendor has not packaged dbus like that, perhaps ask them to
look at how it's done in Debian? Or if they have deliberately chosen
not to support multiple D-Bus sessions per logind user-session, then
that OS distribution is not suitable for your requirements, and you
need to change either your requirements or your OS distribution.

systemd-devel mailing list

Re: [systemd-devel] Spurious failures starting ConnMan with systemd

2016-11-21 Thread Simon McVittie
On Tue, 15 Nov 2016 at 16:02:07 +0100, Daniel Wagner wrote:
> commit 09aa0243aac40ec4e5bd0fbe41e702be4952a382
> Author: Patrik Flykt 
> Date:   Thu Sep 17 10:42:46 2015 +0300
> connman.service: Fix dependencies for early boot
> Unset default dependencies in order to properly run at early boot and
> require the save directory to be mounted before starting.
> See the systemd.unit man page, Debian's wiki page
> and the upstream
> systemd-networkd.service file for details.

dbus-daemon is not (currently) designed to be usable as an early-boot
service. You cannot be an early-boot service and depend on D-Bus - you
don't get to "have your cake and eat it".

See also and

Especially these comments:

(#c6 explains the significant feature work that would have to happen in
dbus-daemon to make it a viable early-boot service.)

systemd-devel mailing list

Re: [systemd-devel] systemd-timesyncd: Cannot resolve user name systemd-timesync: No such process

2016-11-11 Thread Simon McVittie
On Fri, 11 Nov 2016 at 15:13:00 +0100, Michael Hirmke wrote:
> Does anyone know, what "+::" in /etc/passwd means?

It's to do with the NSS "compat" plugin, which glues together
NIS and a traditional password file.
Look for "Compatibility mode (compat)" in

systemd-devel mailing list

Re: [systemd-devel] No rhyme or reason to systemd enabling/disabling service

2016-07-29 Thread Simon McVittie
On 29/07/16 18:56, Simon McVittie wrote:
> So I'm not sure what you're doing, or
> where your dnscrypt-proxy.{socket,service} came from.

It's a bug in the Debian/Ubuntu packaging for dnscrypt-proxy, which have
their own fork of the systemd units, possibly derived from 1.6.0. I've
opened a bug in the Debian bug tracking system.

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] No rhyme or reason to systemd enabling/disabling service

2016-07-29 Thread Simon McVittie
On 29/07/16 18:46, Chip wrote:
> And I believe, yes, network must be operating before
> dnscrypt-proxy activates.  I'm guessing that some configuration file in
> /etc/systemd/system/ needs tweaking?

My normal advice would be to talk to dnscrypt-proxy upstream or the
supplier of your dnscrypt-proxy package... but if you're running Ubuntu
16.04, then you should have version 1.6.1, and this bug already appears
to have been fixed before 1.6.1. So I'm not sure what you're doing, or
where your dnscrypt-proxy.{socket,service} came from.

The change you need appears to be
and maybe
if that isn't in the version you're running.

It's dnscrypt-proxy.{socket,service} in /usr/lib/systemd/system or
/lib/systemd/system depending on distribution, although you can copy
them into /etc/systemd/system to make local modifications (or use
"drop-ins", see systemd.unit(5)).

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] No rhyme or reason to systemd enabling/disabling service

2016-07-29 Thread Simon McVittie
On 29/07/16 16:59, Chip wrote:
> On 07/29/2016 05:57 AM, Lennart Poettering wrote:
>> My educated guess is that some cyclic dependency or so caused it to
>> not be considered for activation at boot.

Lennart's guess was correct:

> Jul 29 11:33:06 blablabla systemd[1]: Found ordering cycle
> on
> Jul 29 11:33:06 blablabla systemd[1]: Found dependency on
> Jul 29 11:33:06 blablabla systemd[1]: Found dependency on
> dnscrypt-proxy.socket/start
> Jul 29 11:33:06 blablabla systemd[1]: Found dependency on
> Jul 29 11:33:06 blablabla systemd[1]: Found dependency on
> NetworkManager.service/start
> Jul 29 11:33:06 blablabla systemd[1]: Found dependency on
> dbus.service/start
> Jul 29 11:33:06 blablabla systemd[1]: Found dependency on
> Jul 29 11:33:06 blablabla systemd[1]: Breaking ordering
> cycle by deleting job

You have asked systemd to do something impossible: depends
on dnscrypt-proxy.socket, which depends on, which
indirectly depends on systemd can't start them all in the
requested order, so it breaks the cycle in an essentially random place.

The bug here is probably that the dnscrypt-proxy.socket *socket* unit
should not depend on anything. You probably intended the corresponding
*service* unit, dnscrypt-proxy.service, to depend on instead?

A socket unit just means systemd is listening on a socket: there's no
reason for it to depend on anything (except perhaps the creation of the
necessary directories, if it's an AF_UNIX socket). If you need the
network to be up before dnscrypt-proxy actually starts, then it's
dnscrypt-proxy.service that needs the dependency.

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] Standardizing names for graphical session units

2016-07-05 Thread Simon McVittie
On 04/07/16 21:01, Martin Pitt wrote:
> A session type like "GNOME" or "KDE" then defines which top-level
> servcies it wants.

Could this be done by having the .desktop file in /usr/share/xsessions
or /usr/share/wayland-sessions start an appropriate systemd user unit
directly, and wait for it to terminate?

> Ideally we could hook the startup of graphical.slice into the system
> logind scope; but as the user systemd does not "see" the
> systemd users, this isn't possible. So for now pretty much the only
> way is to go via an /X11/xinit/xinitrc.d (Fedora) or
> /etc/X11/Xsession.d/ (Debian) script

These scripts are a necessary evil for X11, but in the Wayland future,
the plan (at least in GNOME) seems to be for them not to be replicated;
if gdm is told to launch a session from /usr/share/wayland-sessions, it
doesn't execute X11 startup script snippets. (It does have a
gdm-specific way to set environment variables, and I'm planning to
extend pam_env to support systemd-style .d drop-in directories to
generalize that.) A more declarative session startup seems like a better
session startup.

I'm not sure what you do for Mir in Ubuntu, but I'd advocate a similar
approach - sourcing a couple of dozen Turing-complete shell script
fragments during session startup makes it rather difficult to reason about.


Simon McVittie
Collabora Ltd. <>
systemd-devel mailing list

Re: [systemd-devel] How to mount NFS prior to start postgresql from this volume

2016-07-01 Thread Simon McVittie
On 01/07/16 15:44, wrote:
> Maybe it is caused by this  (ssome lines before in journalctl-log):

I don't know whether it's causal, but dependency loops are never good news.

> Jul 01 16:09:57 postgis1 systemd[1]: Cannot add dependency job for unit
> display-manager.service, ignoring: Unit display-manager.service f
> Jul 01 16:09:57 postgis1 systemd[1]: Found ordering cycle on
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
> rpcbind.service/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
> vmware-tools.service/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
> Jul 01 16:09:57 postgis1 systemd[1]: Breaking ordering cycle by deleting
> job rpcbind.service/start
> Jul 01 16:09:57 postgis1 systemd[1]: Job rpcbind.service/start deleted
> to break ordering cycle starting with

I think I recognize this from when Debian switched default init system
to systemd.

Part of the problem is that rpcbind is an early-boot service (rcS, but the version in Debian 8 doesn't have a native
systemd service, only an LSB init script in /etc/init.d. systemd has a
generator that can fake a service from that script, but because it
doesn't have all the necessary information and has to make some
assumptions, it's easy for it to create a dependency loop that could
have been avoided when using native services.

This is fixed in testing (stretch); a backport of the version from
stretch, or introducing native systemd services locally, would probably
help. See <> for
more on this general topic. rpcbind's Debian maintainer does not appear
to be working on it any more, so I suspect it might be in danger of not
releasing with Debian 9; if NFS is important to you, you might want to
look into taking over its maintenance.

I think vmware-tools might be in a similar situation: relatively early
boot, but only a LSB init script, not a native systemd service.

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] how to use per-user systemd --user services / how to replace /etc/xdg/autostart/app.desktop?

2016-06-20 Thread Simon McVittie
On 16/06/16 14:10, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Jun 16, 2016 at 12:32:24PM +, Patrick Schleizer wrote:
>> Using Debian jessie (stable) with systemd package version 215-17+deb8u4.
> I'd suggest looking at existing user units present in
> Debian, converting some more packages where this makes sense, and
> submitting those unit files to the Debian maintainers to integrate
> them in the distribution or upstream.

This sort of structural change is not going to be included in Debian 8
"jessie" - that would defeat the purpose of a long-term stable
distribution. Please develop patches against Debian testing/unstable, so
that they can go into the *next* stable Debian release (Debian 9
"stretch". You can also incorporate those patches into your
locally-installed packages on jessie if you want, but Debian package
maintainers certainly won't apply them to jessie.

A good starting point is to turn D-Bus session services into systemd
user units, as I already did for a few packages (for example
evolution-data-server and gnome-terminal-server). I have mostly been
submitting these as patches upstream, with backports into older upstream
versions in Debian testing/unstable in some cases.

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] Sync mail with offlineimap via systemd service/timer; getting password from gnome keyring

2016-06-20 Thread Simon McVittie
On 16/06/16 12:01, Ruben Verweij wrote:
> However, I am storing my password via the gnome-keyring and retrieving
> it via `secret-tool lookup user [user] domain
> <>`.
> I already found out that the problem might lie in the dbus
> communication, but I'm not sure how to fix it. Can anyone provide an
> insight?

If you want non-X11 environments to have a D-Bus session bus, you need
to configure dbus >= 1.10 with --enable-user-session at compile time. On
Debian derivatives, install the dbus-user-session package; on
non-Debian-derived distributions, it might be enabled unconditionally
(as on recent Fedora and Arch), or there might be some equivalent step
you have to take, or it might even not be possible at all.

libsecret uses D-Bus to communicate with gnome-keyring, which is why
this is relevant.

Simon McVittie
Collabora Ltd. <>
systemd-devel mailing list

Re: [systemd-devel] question on special configuration case

2016-06-08 Thread Simon McVittie
On 08/06/16 03:04, Hebenstreit, Michael wrote:
>> What processes are showing up in your count?  Perhaps it's just a bug that 
>> needs to be fixed.
> /bin/dbus-daemon
> /usr/lib/systemd/systemd-journald
> /usr/lib/systemd/systemd-logind

dbus-daemon will wake up when there are D-Bus messages to be delivered,
or when D-Bus-related data in /usr/share/dbus-1/ changes. If there is
nothing emitting D-Bus messages then it shouldn't normally wake up.

In dbus >= 1.10 you can run "dbus-monitor --system" as root, and you'll
see any D-Bus message that goes past. Unfortunately this use-case for
monitoring didn't really work in previous versions.

If you want it to stay off the majority of your CPU cores, Greg's
recommendation to set up CPU affinity seems wise. dbus-daemon is
single-threaded (or 2-threaded if SELinux and the audit subsystem are
active), so it will normally only run on one CPU at a time anyway.

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] /usr/lib/systemd/*.wants vs. Wants in unit definition

2016-06-06 Thread Simon McVittie
On 06/06/16 15:17, Martin Pitt wrote:
> Of course it could also just do the usual WantedBy= in the unit and
> call systemctl enable on installation (that's what the Debian package
> does)

Most Debian packages with systemd services do this, but there are

> but there are cases where you don't really want to make the
> enablement configurable by the admin.

One example of this is dbus.service, which is statically enabled by
shipping symlinks in /lib/systemd/system in the .deb (as befits its "OS
infrastructure" status, in particular as something that is used by other
systemd components).

Conversely, polkitd.service is statically *disabled* (it doesn't ship
symlinks in the .deb and doesn't have a WantedBy), so it can be started
on-demand via D-Bus activation, but is never started "eagerly" during
boot (there would be no point).

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] why does bootctl default to /boot and not to /boot/efi?

2016-05-30 Thread Simon McVittie
On 29/05/16 19:39, Barry Scott wrote:
> I just came across the bootctl command. Atleast on Fedora 23 and 24
> it errors out because /boot is not FAT EFI. I thought that if you are EFI
> then the EFI was always in /boot/efi.

I think mounting the EFI System Partition on /boot/efi is likely to be
very common in practice. The kernel images in /boot are managed by dpkg
on Debian derivatives, and dpkg requires (or at least strongly
recommends) a POSIX filesystem on the directories it manages, so that it
can do standard POSIX filesystem robustness tricks like hard links and

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] Supporting properties(configurations) system

2016-03-07 Thread Simon McVittie
On 07/03/16 02:46, WaLyong Cho wrote:
> As you may know, Android has properties.
> In the desktop side, it maybe similar with configuration system such
> like gconf.

gconf and its more modern replacement dconf are for per-user settings.
If that's what you want, I would suggest dconf - or preferably a
framework like GLib's GSettings or Qt's QSettings, which just provides a
data model and can support multiple backends (dconf, restricted views of
dconf proxied into an app container, flat file, Windows
HKEY_CURRENT_USER registry, etc).

Per-user settings like dconf and HKEY_CURRENT_USER should not be
confused with per-system settings, like Windows' HKEY_LOCAL_MACHINE
registry. On Unix systems, per-system settings are usually stored in
plain files in /etc, like the ones in /etc/systemd/system/ that
configure systemd.

> I hope the configurations are supporting write protected(ro) and
> writable(rw). To control this, I think new daemon will be needed and the
> daemon has to be activated before the clients(user of the configuration
> system).

Depending on your exact requirements, it might be a better fit to use
plain files, inotify and no daemon. Normal Unix DAC permissions, or
LSMs' MAC policies, can provide read-only and read/write.

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] [RFC] the chopping block

2016-02-12 Thread Simon McVittie
On 11/02/16 17:06, Lennart Poettering wrote:
> 5) Here's the controversial one I think: support for booting up
>without /var. We have kludges at quite a few places because we
>cannot access /var early during boot.

I don't think /var is really the same thing as /usr: for a start, it has
to be read/write, whereas /usr and / can be read-only for at least the
early stages of boot.

On stateless systems with a read-only / and /etc, requiring /var to be
mounted from the initramfs would mean that the mechanism for setting up
/var (NFS or tmpfs or whatever) would have to move into the initramfs.

Which specific subdirectories of /var do you want mounted before pid 1
starts? Presumably /var/lib/systemd and /var/log, and everything that's
necessary to mount those, but not necessarily their siblings?

Would it be feasible to buffer read/write stuff in /run until /var comes
up, and then write it out afterwards? (I realise that's already how some
of it works, notably the Journal.)

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] euid 0 not honored authenticating control socket?

2016-01-25 Thread Simon McVittie
On 21/01/16 18:12, Charles Duffy wrote:
> I have a setuid-root executable

... and now you have two problems? :-)

setuid executables are inherently dangerous: they run with one set of
privileges (their euid), but their environment variables, resource
limits, inherited file descriptors, etc. are controlled by a different,
usually lower set of privileges (their real uid). Every piece of code
run in this rather precarious situation needs to be designed to distrust
things that normal application code can safely trust.

Executables that are not specifically designed to be run under setuid
(including systemctl), and libraries that are not specifically designed
to be setuid-safe, should not be run while setuid.

If you are completely confident that your setuid executable has
sanitized its environment - most importantly, cleaning the environment
via a whitelist, like
<> does -
then you can set the real and effective uids to the same value,
effectively taking responsibility for dealing with the security boundary.

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] How to suppress coredumps when systemd-coredump is in use?

2016-01-12 Thread Simon McVittie
On 12/01/16 17:51, Lennart Poettering wrote:
> On Fri, 08.01.16 17:31, Robert O'Callahan ( wrote:
>> Maybe systemd could query the
>> dumping process's RLIMIT_CORE with prlimit() and throw the coredump away if
>> the limit is 0.
> Yes, we really should check RLIMIT_CORE of the dumped process, and
> honour it. Happy to take a patch for that!

Please see the thread around
(explaining the reason why the kernel still dumps cores to pipes when
the limit is 0) before doing so. Neil Horman writes:

The case (ispipe==true && cprm.lmit==0) has to result in us dumping
a core. I use to be convinced otherwise, but several user space
developers changed my mind, particularly the guys writing the abrt
daemon.  The reason being, the default process limit for
RLIMIT_CORE is zero.  If you're writing a daemon like abrt that
wants to catch program crashes, even during boot, there are tons of
hoops you have to jump through to get core pipes enabled properly
if you need to change RLIMIT_CORE.  Specifically you have to modify
all existing processes RLIMIT_CORE values to be non-zero (a racy
proposition) as well as modify the init processes RLIMIT_CORE value
(so that it gets inherited by future processes).  Thats a pretty
rickety thing to set up, and they really didn't want to have that
much fiddling to do to get it all working, and I don't blame them.

If systemd's pid 1 has a way to set RLIMIT_CORE globally (including for
itself), then perhaps that argument doesn't hold on system systems, but
it's something to think about before making this change.

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] How to unlock a blocking sd_bus_wait() call

2016-01-08 Thread Simon McVittie
On 07/01/16 20:15, Iñigo Martínez wrote:
> Do you think that it is a good idea a thread using sd_bus_wait that
> can be cancelled and cleaned later ?

You had a problem and you solved it with threads, and have two now you
problem[Segmentation fault, core dumped.] :-)

If you use an event loop like Lennart suggested (or if you use sd-event
or GLib or something), then you shouldn't need to multi-thread your
socket operations anyway, and D-Bus is basically socket operations.

Based on my experience with libdbus and GDBus, I don't think the
"optionally threaded" design from libdbus is a sensible one. A D-Bus
implementation can either do all its real work in a worker thread and
require message-passing from user code in other threads, like GDBus, or
do all its real work in the caller's thread (and require that each
connection is owned/used by only a single thread), like sd-bus and the
practical recommendation for how to use libdbus reliably. libdbus has
the worst of both worlds - it tries to support arbitrary API calls from
arbitrary threads, which in practice just means it fails to work in
corner cases if you're multi-threading, and has pointless locking
overhead if you're using it single-threaded.


Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] User service with suid executable

2016-01-08 Thread Simon McVittie
On 07/01/16 23:14, Martin Novák wrote:
> I've created this (toy) user service for running desktop of differnt
> user

I don't think a user service is an appropriate tool for this job. If you
have sudo privileges, you can use a system service, or perhaps even a
user service that runs as the other user.

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] How to suppress coredumps when systemd-coredump is in use?

2016-01-08 Thread Simon McVittie
On 08/01/16 04:31, Robert O'Callahan wrote:
> has a test suite which runs a lot of programs that
> intentionally crash with core-dumping signals.

dbus has a similar thing in its test suite. The feature you want is



Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] Query regarding "EnvironmentFile"

2015-12-10 Thread Simon McVittie
On 09/12/15 19:46, Lennart Poettering wrote:
> Also /etc/sysconfig is a Redhatism
> that should really go away, the whole concept is flawed.

This is by no means limited to Red Hat derivatives: /etc/default is a
Debianism which is basically the same as /etc/sysconfig.

I think Red Hat and Debian derivatives do both over-use their respective
EnvironmentFile directories (and in particular the START_DAEMON=0
anti-pattern, which was a workaround for how hard it traditionally was
to disable a service in sysvinit, needs to go away), but it can make
sense for the specific case of overriding non-system-integration-related
command-line options, to avoid situations like this:

* foobar version 1 has ExecStart=/usr/libexec/foobar --no-fork
* sysadmin overrides that to
  ExecStart=/usr/libexec/foobar --no-fork --enable-uploads
* distribution or upstream changes version 2 to say
  ExecStart=/usr/libexec/foobar --no-fork --use-syslog
  (or some other new system-integration option)
* desired result: --no-fork --use-syslog --enable-uploads
* actual result if the sysadmin has used systemctl edit:
  --no-fork --enable-uploads

by having "ExecStart=/usr/libexec/foobar --no-fork [--use-syslog]
$OPTIONS" instead.

Of course, it would be better for the underlying service to have a
configuration file (or, better, a .d directory) where the sysadmin could
enable uploads; but we have to work with what we have, not what we'd
like to have, and not all underlying services have that.

The approach I try to follow in dbus is that options that should be
changed by another package (such as default security policies) go in a
configuration file, or more recently a file in /usr/share; options that
should be changed by the sysadmin (such as security policies and
resource limits) also go in a configuration file; but system-integration
options (such as "use syslog" or "use systemd for activation") are
command-line options that can be forced to their
correct-for-this-distribution values by the ExecStart line in the
systemd unit, LSB init script or whatever. Unfortunately dbus doesn't
always follow this rule for historical reasons -  is a
configuration-file option, but it shouldn't be.

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] [help][227] Enabling a user service breaks a little my system!

2015-11-26 Thread Simon McVittie
On 26/11/15 06:33, Jorge Araya Navarro wrote:
> $ LC_ALL=C systemctl --user
> Failed to connect to bus: No such file or directory

Do you have a D-Bus session bus as a user service?

If you are using Debian or one of its derivatives like Ubuntu, install
the dbus-user-session package. This is probably what you want if you
like user services, but do read its Description first, because it
changes the interpretation of the D-Bus session bus system-wide.

If you are using Arch Linux, I think recent versions of their dbus
package make the session bus into a user service unconditionally.

If you are using some other distribution, talk to your distribution's
dbus and systemd maintainers. I would suggest that distributions that
are conservative about backwards-compatibility should package the user
session bits separately so that they are an opt-in (like I did in
Debian), and bleeding-edge/"legacy-free" distributions should just
enable them (like in Arch Linux).

If you are compiling your own dbus (>= 1.10), or you *are* your
distribution's dbus maintainer, the --enable-user-session configure
option is the one that makes the session bus into a user service. It
just installs some extra files: on Debian, we always enable that option,
but we split the files into the dbus-user-session package instead of
including them in the main dbus package.

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] [packaging] split of systemd package

2015-11-12 Thread Simon McVittie
On 12/11/15 08:59, Lennart Poettering wrote:
> The
> other option of course is to declare all internal APIs exported .so
> symbols, but that would mean to commit to a stable API for them (which
> is completely out of the question), or to bump the soname on each
> release (which is not an option either).

Have you considered doing something similar to what recent dbus versions
do for libdbus?

* symbols starting dbus_ (except for a couple of historical accidents
  that start with dbus_internal_do_not_use_) are explicitly stable ABI

* symbols starting _dbus_ are explicitly not stable ABI, and are only
  used (outside libdbus) by dbus-daemon and other utilities in the dbus
  source package

* symbols starting dbus_ are versioned (GNU symbol-versioning)
  as LIBDBUS_1_3 (as long as the shared library is

* symbols starting _dbus_ are versioned as LIBDBUS_PRIVATE_1.10.2
  which deliberately changes with each new version

This only applies to our equivalent of systemd's src/basic (the parts
that are needed by both the libdbus public API and the utilities). Our
equivalent of src/shared still ends up in a convenience library that is
statically linked into each utility that needs it.

It's a little easier for systemd to rely on this than it is for dbus to
do the same, because dbus is portable (to Windows, non-GNU Linux, and
non-Linux Unix like *BSD and Solaris), whereas systemd only targets
GNU/Linux and can assume that GNU symbol versioning is present in libc.

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] Help writing a user service file that will exec a command upon system sleep

2015-10-29 Thread Simon McVittie
On 29/10/15 18:52, John wrote:
> This is an interesting idea but I would like to learn about user units and 
> sleep mode :)

I think the intention is that per-user code deals with sleep by having a
service (daemon) that registers to inhibit suspend; when it is notified
that systemd would like to suspend, it does what it needs to do, then
releases the inhibit to allow suspend to continue.

Here's a working implementation (it also handles two flavours of network
connectivity, but you can ignore those bits), which Telepathy uses to
try to log out from IM services before suspending:

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] Secret machine-id for RFC 7217 stable addresses

2015-10-09 Thread Simon McVittie
On 08/10/15 21:47, Tom Gundersen wrote:
> On Mon, Sep 7, 2015 at 7:49 PM, Lubomir Rintel <> wrote:
>> This sounds a bit like machine-id, unfortunately given it's world
>> readable and available via DBus (and possibly on a network?) it
>> doesn'tseem to be secret enough.

For context, the D-Bus machine ID (on which the systemd machine ID was
based) was intended to be used somewhat like the hostname, except with
the expectation that it is actually unique (unlike hostnames, which are
user-meaningful and therefore somewhat likely to collide). For instance,
GNOME's displays control panel stores a separate monitor layout per
machine ID, so that each machine has its appropriate monitor layout even
if they NFS-share a home directory.

Like a hostname, the machine ID is not really meant to be secret; for
instance, I think it would be OK to use the machine ID as a fallback
hostname, which could result in it being sent over the network in DHCP
or mDNS packets.

> A priori, it would perhaps have been nice to consider the real
> machine-id on disk to be "secret", and only ever expose a hash of it

How secret is "secret" here? Readable by root only? Readable by root and
system users? Readable by all local users? If a system component like
systemd (or D-Bus for that matter) is going to provide this as a "system
API", then it needs to be well-defined.

From the D-Bus point of view, in new installations it seems fine to use
the hash of a random secret as a basis for the world-readable machine
ID. However, in existing installations that are upgraded, the old
machine ID should always be preserved.


Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] Possible confusion with socket activation and daemon own configuration

2015-09-08 Thread Simon McVittie
On 08/09/15 13:55, Francis Moreau wrote:
> On 09/08/2015 12:09 PM, Richard Maw wrote:
>> I understood that the common configuration for socket activated sshd was to
>> have a sshd.service for if you want it to always be running, and a pair of
>> sshd@.service and sshd.socket.
> Ah no, with this design starting sshd.service should do the right thing
> but that's because there're 2 different service unit files:
> sshd@.service and sshd.service.

As far as I understand it, this duplication is present to give the
sysadmin a choice between two ways to run sshd, depending on this
particular ssh server's requirements.

If ssh access is frequently used or needs to work quickly (for instance
as the primary way to log in and fix things), enabling sshd.service
means it will start "eagerly", on boot. Debian and its derivatives
enable this by default (if sshd is installed).

If ssh access is infrequently used, a sysadmin can disable sshd.service
and enable sshd.socket instead. That means sshd will be started
on-demand, which will take a bit longer (particularly if the reason to
log in is that the server has hit performance problems), but reduces
resource consumption until then. This would be appropriate if the reason
for providing ssh access is as a rarely-used "developer console"
analogous to Android's adb, for instance.

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] bootctl: default mount point for the ESP partition.

2015-09-01 Thread Simon McVittie
On 01/09/15 17:21, Goffredo Baroncelli wrote:
> I discovered that bootctl assume as default mount point for the ESP
> partition the /boot directory. Instead it seems to me that the most part
> of distributions prefers /boot/efi.

For some context, the reasoning for /boot/efi is:

In some distributions (presumably including the (Fedora-based?) ones
where this feature was developed), /boot is traditionally treated as
mutable and unpackaged, like /var; so the packages include the kernel in
/usr or /lib or something, and copy it into /boot. The cost of this is
one extra copy of the kernel on-disk, which used to be a significant
amount of space, although on modern disks it doesn't really matter.

In other distributions (like Debian and its derivatives), the OS
packages for kernels traditionally include /boot/vmlinux-whatever and
/boot/config-whatever as packaged files; the corresponding initramfs is
generated at install time and placed alongside them. In these
distributions, there is no second copy of the kernel in /usr or /lib.
This saves some space, although, again, the amount of space saved is
negligible on current hardware.

On BIOS systems, either way was fine, because /boot was either part of
the root filesystem, or a separate small ext2 partition near the
beginning of the drive (to work around BIOS disk-addressability
limitations) for use by lilo or grub or whatever. Similarly, on non-x86,
the bootloader would traditionally either load the kernel from a
non-filesystem like a raw flash partition, or from the root filesystem
or a separate /boot partition; either would be fine.

However, it starts to matter with the move to EFI (on x86 and
elsewhere), or on non-EFI systems where the bootloader also reads a FAT
partition (such as the Raspberry Pi). If the OS packages for kernels
include files in /boot, then having a non-Unix filesystem for /boot
becomes a problem, because the package manager (e.g. dpkg) can't use the
same hardlink-based atomic-overwrite that it would use for robustness on
a proper Unix filesystem. The ESP is FAT, which is not a full Unix
filesystem, so you can't do that sort of thing. That's why Debian and
its derivatives mount the ESP at /boot/efi instead of /boot, and why
<> mounts the
ESP-equivalent at /boot/firmware.

AIUI, /boot/efi also makes it a bit easier to have the ESP remain
unmounted or read-only when not in active use, which is good for its own
robustness; a system crash corrupting an unmounted partition is less
likely than corrupting a mounted filesystem.

In principle, it should be possible for the ESP to never be mounted at
all, copying files in with mtools (or equivalent) when required.

Simon McVittie
Collabora Ltd. <>

systemd-devel mailing list

Re: [systemd-devel] Who has rights to override/ignore inhibitors?

2015-08-24 Thread Simon McVittie
On 21/08/15 17:04, Jayson Willson wrote:
 However, on my system, without any special
 polkit configuration standard user (which is in the groups mentioned
 above) can ignore inhibitors by running systemctl poweroff -i without
 being asked for authentication.

For the benefit of the list, it appears the answer to this was that
there is some confusion between reasons the system might not want to
let me power off and inhibitors, and that Jayson was looking at
.power-off-ignore-inhibit while the real logind permission being tested
was .power-off-multiple-sessions.

Full details:

Simon McVittie
Collabora Ltd.

systemd-devel mailing list

Re: [systemd-devel] Systemd --user and the role of DBUS API

2015-08-19 Thread Simon McVittie
On 19/08/15 14:12, Mantas Mikulėnas wrote:
 sd-bus has better performance and native
 kdbus support (and a better API than e.g. dbus-glib), but if you're
 writing programs in GTK or Qt or EFL, then you'll still want GDBus or
 QtDBus or Eldbus.

To clarify, *everything* has a better API than dbus-glib. libdbus, the
low-level reference implementation that is described as painful by its
own documentation, is better than dbus-glib. Please don't use dbus-glib.

If you don't care about portability beyond Linux, sd-bus is essentially
a better libdbus; if you do care about portability beyond Linux, sd-bus
is unsuitable.

 The current devel branch (1.9.20) of dbus-daemon installs the
 --user units dbus.socket and dbus.service necessary for this.

It only does that if you configure with --enable-user-session. It is
currently opt-in, because it changes the semantics of how the OS is put
together, and some people seem to feel very strongly about the
historical per-login-session buses. I might swap the user bus from
opt-in to opt-out in 1.11 or 1.13 or something. On Debian and its
derivatives, installing the dbus-user-session package has the same
effect as --enable-user-session (and I'd encourage other general-purpose
distributions to use similar packaging).

dbus 1.9.20 is about to become dbus 1.10.0 with only trivial changes, so
a stable branch with optional user-bus support is (finally) around the

 The user bus address is

... tried by default in libdbus 1.9, GLib 2.45, and sd-bus; so you don't
need to set DBUS_SESSION_BUS_ADDRESS at all, unless you need
compatibility with older versions, or reimplementations like dbus-sharp.

 (Technically the same can be done with dbus 1.8.x as well, but AFAIK the
 developers do not approve.)

We don't add features in stable-branches, particularly features that
change semantics, so libdbus 1.8.x does not have the necessary code
changes to make the right things for a user-bus happen by default. You
can backport them, at your own risk; or you can just parachute in the
dbus.socket and dbus.service files and not make the code changes, but
then setting DBUS_SESSION_BUS_ADDRESS appropriately is your responsibility.

Simon McVittie
Collabora Ltd.

systemd-devel mailing list

Re: [systemd-devel] Suggestion for a lowlevel fsnotify change daemon.

2015-07-28 Thread Simon McVittie
On 28/07/15 17:28, Mantas Mikulėnas wrote:
 At first look, this seems very similar to FAM (which even supported
 NFSv3, using custom notifications over SunRPC).
 Later I remember GNOME replaced it with Gamin and finally with
 local-only inotify inside glib/gvfs.

What GLib actually uses is an abstraction with multiple backends,
including inotify (the default on Linux) and FAM; so in principle it
could have a backend for some new thing, or even use inotify for normal
local filesystems and the new backend for other mounts.


 On Jul 28, 2015 18:46, Stef Bon wrote:
 - I had to add some calls to the fuse library to push changes to
 the VFS where there is no direct related call from the VFS. (files
 are added and/or files are changed)
 - the FUSE kernel module in VFS has to trigger fsnotify call when
 events are pushed to the VFS by the userspace daemon.

If you're adding a monitoring/notification call to FUSE, would it be out
of the question for the user-space API to it to be exactly use
inotify? (Or fanotify, or whatever is believed to be the right
user-space API for file monitoring these days.)

 It should also be able to forward a watch to a filesystem like
 FUSE and cifs and nfs, so that they know a watch has been set.
 They can act then on it, by forwarding the watch to the backend. SMB
 does upport this, NFS4 also, and you can make FUSE also support
 it(depending the protocol).

If the in-kernel implementation of NFS or CIFS isn't enhanced to support
monitoring, this can't work.

If the in-kernel implementation of NFS or CIFS *is* enhanced to support
monitoring, is there any reason for the kernel not to present the
resulting information to user-space via inotify? In other words, is
there a reason why a user-space service is necessary?

(I realise that one possible reason for a user-space service is so that
it can aggregate all the periodic polling, on filesystems that don't
have anything better you can do - that's why FAM had a daemon, if I
remember correctly.)

Simon McVittie
Collabora Ltd.

systemd-devel mailing list

Re: [systemd-devel] Monitoring services start event from kdbus with sd-bus API

2015-06-30 Thread Simon McVittie
On 30/06/15 10:15, Thomas Schmidt wrote:
 r = sd_bus_add_match(bus, NULL, , do_something_callback,  NULL); /* should 
 not filter anything, I expect it triggers on any message */ 

Eavesdropping (adding match rules with AddMatch to receive messages
that are neither a broadcast, nor directed to you) has never worked
reliably on the system bus in traditional D-Bus, cannot be made reliable
on the system bus without introducing security flaws, and does not exist
at all in kdbus.

Monitoring is the modern replacement for eavesdropping: it puts your
connection in a special mode where it receives other people's messages,
but cannot send messages or do other normal D-Bus things. kdbus has only
ever had monitoring, not eavesdropping, and I added a vaguely similar
monitoring mode to dbus-daemon in the 1.9.x development branch.

Monitoring and eavesdropping are both unusual things that should only be
used as a diagnostic, and not in production code. Think of them as
equivalent to putting your network interface in promiscuous mode for
something like tcpdump - you can do that as a developer or sysadmin to
debug problems or detect bad behaviour, but you shouldn't write ordinary
networking applications that rely on it.

 The interesting thing is that this code only sees „signal“ type  messages - 
 but not any other like „method_call“.

That is consistent with the way in which eavesdropping has never really
worked as intended on the system bus.

Further reading:

Simon McVittie
Collabora Ltd.
systemd-devel mailing list

Re: [systemd-devel] Can kdbus send signal to the source connection?

2015-06-15 Thread Simon McVittie
On 15/06/15 15:32, Lennart Poettering wrote:
 Did I get this right, you have one bus connection per thread, but
 possibly both a kdbus client and its service run from the server, and
 you want broadcast msgs sent out from one to then also be matchable by
 the other?

If this is indeed what eshark means, then talking to yourself like
this is something that always used to work with traditional D-Bus (as
long as you make sure to never block waiting for a reply!), so it's a
regression if it doesn't work with kdbus.

In traditional D-Bus, broadcasts go to any connection that has
registered its interest in the broadcast via AddMatch. dbus-daemon does
not discriminate between the sender of a message, and other connections
- in particular, it will send a copy of a broadcast back to its sender,
if that's what the sender asked for.

Various projects' regression tests work like this: they run the
client-side and service-side code in the same GLib main loop and do
everything asynchronously, and it works. Ideally, the only processes
involved are the test and the dbus-daemon (and under kdbus the
dbus-daemon would not be needed either).

 Can't you dispatch that locally? i.e. in addition to passing the msg
 to kdbus also enqueue it locallly along the kdbus fd, or so?

That would mean re-ordering the broadcast messages (taking them out of
their correct sequence relative to other messages), which is one of the
reasons why traditional D-Bus implementations don't optimize messages
to yourself in this way. One of dbus-daemon's roles is to impose a
total ordering on messages - it's the component that makes the arbitrary
decision on how the individual message streams get interleaved.

Simon McVittie
Collabora Ltd.

systemd-devel mailing list

Re: [systemd-devel] nss-myhostname: why don't loopback interfaces appear?

2015-06-10 Thread Simon McVittie
On 10/06/15 03:18, Daurnimator wrote:
 example use case, I'm testing a client/server protocol:
   - the server is running locally; and because it shouldn't be exposed
 to the internet, it is bound to localhost.
   - I start the client and tell it to connect to $HOSTNAME

Why wouldn't you tell the client to connect to localhost instead?

(Relatedly, on my development laptop I have dnsmasq set up to resolve
[anything].localhost to, which means I can even use name-based
virtual hosting in local testing - maybe it would be worthwhile for
systemd-resolved and/or nss-myhostname to behave similarly?)

Simon McVittie
Collabora Ltd.

systemd-devel mailing list

Re: [systemd-devel] Creating units using D-Bus

2015-06-10 Thread Simon McVittie
On 10/06/15 11:46, Jóhann B. Guðmundsson wrote:
 I hate to say this since I'm against litter unit files across the entire
 filesystem like infective disease and administrator then have to run
 around trying to chase them down but is it not better to store this
 under /srv somewhere [1], not etc, so it wont conflicts with Stateless
 Systems, Factory Reset, Golden Master Systems?

To me this seems like (programmatically-assisted) configuration by a
sysadmin, just like when NetworkManager writes configured networks into
/etc/NetworkManager, or when `systemctl (en|dis)able` manipulates
symlinks in /etc? You reset to factory configuration by deleting /etc
seems entirely consistent with tool-generated configuration goes in
/etc to me.

/srv is certainly not the place: if no program should rely on a
specific subdirectory structure of /srv (that's a direct quote from the
FHS) then systemd can't rely on a particular directory structure being a
valid place to put its own files. You might say that systemd units could
go in /srv/systemd, but the FHS' point is that it would be, for
instance, entirely valid for the administrators to use
/srv/systemd as the directory for's web content.

This makes /srv pretty useless from a distribution point of view, but
useful for sysadmins - Debian's take on that directory is essentially
don't put anything in /srv out-of-the-box, so that the sysadmin can use
it however they want to (a lot like /opt).

Simon McVittie
Collabora Ltd.

systemd-devel mailing list

Re: [systemd-devel] how to call dbus ListUnits for user units?

2015-05-27 Thread Simon McVittie
On 26/05/15 20:22, Mantas Mikulėnas wrote:
 But right now, the 'user' bus does not exist by default. To create it,
 you need either
 a) enable/install/boot with kdbus,
 or b) obtain the dbus.service  dbus.socket user units. (They're in
 dbus-git, or various other places like

The Correct™ way to get dbus.service/dbus.socket user units these days
is with dbus = 1.9.14 configured with --enable-user-session.

If there are other ways to get similar units (e.g. user-session-units),
please deprecate them. dbus upstream is where this stuff should have
been all along, and in particular, dbus = 1.9.14 is where I've made
sure that libdbus and `dbus-launch --autolaunch` connect to the user bus
(if it exists) by default.

 Configured this way, the 'user' bus won't replace the session bus yet

This is not the case. If there is a user bus, then the session bus *is*
the user bus.


Simon McVittie
Collabora Ltd.
systemd-devel mailing list

Re: [systemd-devel] [PATCH/resend] Use reflinking to copy kernel

2015-05-18 Thread Simon McVittie
On 18/05/15 13:15, Lennart Poettering wrote:
 --reflink=auto is the default in cp since a while.

I think you're thinking of recent mv versions, or a patched coreutils?

cp in current coreutils git never reflinks

unless explictly requested

(line numbers valid as of today's git master)

I believe the rationale is that people invoking cp(1) might expect to
have two entirely independent copies of all the file's disk blocks
afterwards, such that a kernel- or hardware-level bit-flip in one would
leave the other untouched - as opposed to reflinking, in which
*user-space* changes to one leave the other untouched. I don't
personally think that rationale is sufficiently convincing to outweigh
the simplicity of reflinking by default, but I don't maintain coreutils,
and perhaps I'd think differently if I did.

Simon McVittie
Collabora Ltd.

systemd-devel mailing list

  1   2   3   >