Re: [systemd-devel] Restarting dbus service makes system unstable

[Simon McVittie]

On Fri, 08 Mar 2024 at 10:22:50 +0300, Andrei Borzenkov wrote:
> Restarting D-Bus was never safe and never supported. Every individual
> application would need to support D-Bus connection loss and be able to
> transparently reconnect.

None of the client libraries implement this; and if they did, they
would have missed messages during the downtime, which would require
application-specific state recovery which is only possible at the
application level. For example, taking NetworkManager as an arbitrary
example of a D-Bus service: a NetworkManager client like GNOME Shell needs
to do NetworkManager-specific things to "catch up" with any messages that
it missed, and it is not possible to do that generically in a D-Bus client
library without knowing things that are specific to NetworkManager.

> I do not know if D-Bus daemon keeps any internal
> state that would need restoring as well.

Yes, it certainly does keep internal state. I'm pretty sure it isn't
possible to implement the message bus interface without keeping a
significant amount of state.

Being able to restart the message bus safely would require being able to
serialize internal state, store it somewhere (perhaps a file or systemd),
hand off the AF_UNIX sockets to systemd, restart, get the sockets back,
deserialize the state and carry on. I am not aware of any implementations
of that being attempted in D-Bus' 20 year history, and it would be a
relatively large amount of rarely-tested (and therefore buggy) code.

If you are restarting the message bus on a live system, it is most likely
to be because it has a bug or a security vulnerability that you want
fixed; but if that's the case, then the serialized state would need
to be treated as at least partially untrusted, which only makes that
task harder.

(I'm mainly thinking of dbus-daemon here, but I don't see how the
situation could be significantly different for other message bus
implementations like dbus-broker - any message bus is implementing the
same specification, so it needs the same amount of internal state in
order to do its job.)

smcv

Re: Activation environment(s)?

[Simon McVittie]

On Mon, 08 Jan 2024 at 20:42:54 +0300, Vladimir Kudrya wrote:
> On 08/01/2024 19.21, Mantas Mikulėnas wrote:
> > The traditional dbus-daemon keeps a separate environment for services it
> > spawns directly [...], though that it doesn't apply to services it runs
> > via systemd so you need to keep both in sync.

Actually, when you call the dbus-daemon's UpdateActivationEnvironment(),
dbus-daemon >= 1.10.4 will try to upload the same variables to both
dbus-daemon and `systemd --user`, keeping both environments in sync.

`dbus-update-activation-environment --systemd` will also try to upload
the same variables to `systemd --user` (which is redundant since 1.10.4,
but it does it anyway, because it doesn't know whether the message bus
it's talking to has this behaviour).

I say "try" because in some corner cases, for example non-UTF-8 variable
names or values, systemd and/or dbus-daemon will reject particular updates
as not being valid.

As far as I know, the other way round is not true:
`systemctl --user set-environment`, `systemctl --user unset-environment`
and their implementation UnsetAndSetEnvironment() will change the systemd
activation environment, but will not do anything to the activation
environment used by dbus-daemon for traditional D-Bus services (without
SystemdService).

> Is it possible to unset a variable from native dbus execution environment?

It is not possible to unset a variable in the dbus-daemon's activation
environment, or with `dbus-update-activation-environment`: that's an
API limitation in the org.freedesktop.DBus interface. I've thought about
adding an UnsetAndSetActivationEnvironment() that could do this.

It *is* possible to unset a variable in the `systemd --user`
activation environment, with `systemctl --user unset-environment` or
the UnsetEnvironment() and UnsetAndSetEnvironment() D-Bus methods on the
systemd manager. If your distribution is using dbus-broker rather than
dbus-daemon, and if Mantas was correct to say that dbus-broker does not
have its own separate activation environment, then that should be enough
to affect all D-Bus session services. It will also affect all other
systemd user services.

smcv

Re: systemd-sysupdate support for slow rollout (aka A/B testing)

[Simon McVittie]

On Tue, 02 Jan 2024 at 11:16:15 +0100, Lennart Poettering wrote:
> The idea so far was always that the server is dumb, and the client
> picks the release it wants.
> 
> I have thought about this usecase a while back, and my thinking was
> that such a staged update logic should be driven by the machine
> ID. i.e. we should teach sysupdate a simple logic that allows pattern
> matching of new versions based on some arithmetic of the machine
> ID. More specifically, include some value in the URL pattern that
> indicates the percentage of hosts that shall update to this
> release. Then, each client takes its machine ID, treats it as an
> integer and calculates modulo 100 of it or so, and then checks if the
> resulting value is below the intended percentage, and if so it
> updates, otherwise it doesn't.
> 
> (or something like that, the above is probably not ideal, since it
> would mean it's always the same hosts that try a new release first,
> and it probably should be evened out across the set of clients).

Prior art: Debian/Ubuntu apt does slow rollout for packages like
this, with simple filesystem-based http mirrors combined with "smart"
clients. It works by adding a Phased-Update-Percentage field to the
metadata of each package. The client calculates some sort of ID for itself
(I don't know precisely how), and then takes the upgrade if it finds that
its ID is in the first x% of the available range.

If I understand correctly, Ubuntu is using this mechanism in production
but Debian is not.

Using some sort of hash of the machine ID + the proposed version would
probably have the behaviour you want, of choosing a different x% of
machines to be the early-adopter set for each update?

> This would then mean for the server that it would first serve
> foobar_47.11_3.raw which would be version 47.11 of the OS, and 3% of
> the hosts would update to it. And then, once you collected enough
> feedback you'd rename the file to foobar_47.11_25.raw and 25% of the
> hosts would switch over. Finally you'd set the value to 100 (or maybe
> just drop it, which should be considered equivalent to 100), and then
> all remaining hosts would update.

If you're using a hash of the machine ID + the proposed version as
your randomization, then I think you'd want to have a single image (or
version ID, or some other unique identifier) for each proposed update, and
separately, a metadata field that sets *x* in the instruction "if you have
figured out that you are in the first x% of machines, upgrade". Otherwise,
publishing foobar_47.11_3.raw followed by foobar_47.11_25.raw would be
more likely to result in approximately (3% + 25% = 28%) of machines
upgrading[1], because the client doesn't know that it's actually the
same update and would "re-roll the dice" for each republished name.

smcv

[1] more precisely, (0.03 + 0.25 - (0.03 * 0.25)) because of how
conditional probabilities combine

Re: [systemd-devel] Securing bind with systemd methods (was: bind-mount of /run/systemd for chrooted bind9/named)

[Simon McVittie]

On Tue, 18 Jul 2023 at 10:42:49 +0200, Marc Haber wrote:
> That would be /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 on my
> system (only output of find /lib /usr/lib -name 'ld-lin*'), and adding
> that to ExecPaths doesnt allow my Executable to run. So it must be
> something else (possibly in addition).

The interoperable interpreter hard-coded in the ELF header for x86_64
is /lib64/ld-linux-x86-64.so.2 (yes, even on Debian, which otherwise
doesn't generally use lib64). On Debian systems, that happens to be a
symlink to /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2, which resolves to
/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 as a result of the /usr
merge, but those paths are implementation details of Debian rather than
being part of the ABI. In container/namespace contexts you'll likely
need to allow access to this via all three paths.

smcv

Re: [systemd-devel] systemd-stable and Debian's systemd release strategy

[Simon McVittie]

On Wed, 18 Jan 2023 at 16:57:05 +0100, Michael Biebl wrote:
> backports: mostly me lacking time

Also, a note for those who might be less familiar with Debian: the
backports policy is that Debian 11 backports (bullseye-backports)
should always be in sync with the version that would be in Debian 12
(bookworm) if we released Debian 12 today, and similar for other pairs
of Debian versions. We don't backport different upstream versions unless
there are exceptional circumstances.

If Debian 12 was released today, it would contain systemd 252.4-1,
therefore when someone has time to update bullseye-backports, the only
correct thing to update it with would be a backport of that version, as
252.4-1~bpo11+1 (or a backport of whatever newer version has gone into
bookworm by then, if any). There will not be any more 251.x versions
in Debian now that we have picked up 252.x.

The only versions that get special treatment (and will either pick up
releases from systemd-stable or backported bug fixes, depending what
the maintainers are able to justify to the release managers) are the
versions that were current at the time of each Debian stable release
freeze, meaning 247.x for Debian 11, and most likely 252.x for Debian 12.

smcv
(not a Debian systemd maintainer, but I do maintain other packages
that get updated in stable releases)

Re: [systemd-devel] Issue with systemd / journalctl

[Simon McVittie]

On Tue, 27 Dec 2022 at 18:44:42 +0100, syst...@sioban.net wrote:
> I've discovered it's linked to selinux filesystem not mounted
> (don't ask me why, I'm still trying to dig into this...)

Debian does not use SELinux by default (the default LSM is AppArmor), so
if you are using SELinux, you're already in an unusual configuration that
might cause some weird things to happen.

Another thing to watch out for when using LSMs is that they often try hard
to avoid exposing information that could be useful to an attacker, which
might mean that the debug information available to you is incomplete.

On Mon, 26 Dec 2022 at 22:27:52 +, Barry wrote:
> > On 26 Dec 2022, at 14:02, syst...@sioban.net wrote:
> > I've re-installed systemd-sysv and rebooted, cleaned old journalctl entries 
> > but same issues.
> 
> Why do you need the sysv package on a systemd system at all?

It is correct to have systemd-sysv installed on any Debian-derived system
(Debian, Ubuntu, etc.) that will boot using systemd. That package means
"use systemd as init, replacing sysv-rc" because of some implementation
details of how Debian handled the switch from sysv-rc to systemd as its
default init system.

With hindsight, it would have been better if systemd-sysv had been named
systemd-as-init or something, or if it was named systemd and the current
systemd package (which has the actual executables) was instead named
systemd-bin - but renaming packages while maintaining backwards-compat is
really awkward, so we try not to.

The systemd-sysv package only contains a few symbolic links, so
reinstalling it is unlikely to help you much. If reinstalling anything
from the systemd source would have an effect, it would be systemd,
or possibly udev.

I agree that Debian support channels are likely to be a better place to
start for this sort of issue, since people in Debian will be more aware
of the finer points of how things were packaged in whatever Debian release
you're using. Please mention up-front that you are using SELinux, because
that's probably significant and will have an effect on what to try first.

smcv

Re: [systemd-devel] systemd-container: Trying to use a bookworm chroot with a buster host fails / Failed to create /init.scope control group

[Simon McVittie]

On Sat, 03 Dec 2022 at 23:38:55 +0100, Bernhard Übelacker wrote:
> > No SELinux or Apparmor active
> 
> As far as I see in my test VM with minimal Debian Buster there is no SELinux.
> "aa-status" returns "apparmor module is loaded.", but I did not intentionally
> configure anything to it.

Debian uses AppArmor by default (same as Ubuntu), unless you have
intentionally configured it not to. Debian does not use SELinux by default
(again, same as Ubuntu).

> Yes, it is an test to use on an older Debian Buster with kernel 4.19.260-1
> a quite recent Debian Bookworm/testing system.

For those on this mailing list who might not be familiar with Debian
codenames, 'buster' on the host system is Debian 10, an "old stable"
version released in 2019 and maintained by the Debian LTS team. The
recommended stable Debian system right now is Debian 11 (released in
2021) but some change-averse organizations stay on older releases for
whatever reason.

'bookworm' in the container is a development branch of the distribution:
think of it as an alpha or beta of Debian 12. The Debian 12 stable release
is expected to happen in mid 2023.

> So it looks like the failing "syscall_0x1b7" from strace is "faccessat2" [2].
> 
> And it seems "faccessat2" got added just in kernel 5.8 [3],
> therefore it might fail with the kernel 4.19.
> So I fear this needs a newer kernel, and/or this is more a glibc issue then?

The way this is usually meant to work when new user-space runs on an old
kernel is that faccessat2 fails with error ENOSYS, and glibc falls back
to emulating it via an older syscall like faccessat. It's OK for this
fallback to occur, as long as the older syscall gives the right result.
If the fallback gives the wrong result, then that would be a glibc issue
(either an imperfect emulation, or a missing/unimplementable feature on
older kernels).

smcv

Re: [systemd-devel] systemd tries to terminate a process that seems to have exited

[Simon McVittie]

On Tue, 10 May 2022 at 08:44:27 +0300, Yuri Kanivetsky wrote:
> The one running on the host is 215-17 (Debian 8).

That's very old. As far as most of the Debian project is concerned,
Debian 8 reached EOL in mid 2018. There is a separate Debian LTS team
which picks up security support when the main Debian security team drops
a release, but they also stopped supporting Debian 8 in mid 2020.

If you are using ELTS (a third-party commercial offering), I'd suggest
talking to the ELTS maintainers, rather than upstream or Debian -
particularly if you are also using a Debian-8-derived kernel.

smcv

Re: [systemd-devel] Samba Config Reload

[Simon McVittie]

On Mon, 11 Apr 2022 at 09:58:54 +0200, Lennart Poettering wrote:
> dbus-daemon for example uses:
> 
> ExecReload=/usr/bin/busctl call org.freedesktop.DBus 
> /org/freedesktop/DBus org.freedesktop.DBus ReloadConfig
> 
> Which is a synchronous call to reload the config: the daemon is told
> to reload it, and "busctl call" then waits for the reply before
> returning to systemd.

... and, crucially, the implementation of ReloadConfig in dbus-daemon
also waits for its own reload to have actually been done (not just put
in a queue, but actually done) *before* sending back its reply to the
caller (in this case busctl).

If you need to wait for something to have happened, then the whole chain
of interactions needs to be synchronous: all it takes to break the chain
is one component thinking "OK, I'll do that later".

smcv

Re: [systemd-devel] no log information about why machine is sleeping

[Simon McVittie]

On Fri, 13 Aug 2021 at 08:05:29 +0200, Ulrich Windl wrote:
> Amazingly in my Leap 15 system it's GNOME that triggers it: If I'm not logged
> in, no suspend happens, but when I have a GNOME session suspend happens.

If this is not what you want, change the logged-in user's GNOME settings
(via gnome-control-center or the /org/gnome/settings-daemon/plugins/power
dconf tree). While a user is logged in, their per-user settings take effect,
unless systemd-logind is configured to forbid that.

The default in GNOME is to suspend after 20 minutes, to comply with
European and American energy-saving legislation.

smcv

Re: [systemd-devel] automatically restarting services on file changes

[Simon McVittie]

On Tue, 13 Jul 2021 at 23:37:49 -0300, Webstrucs wrote:
> when I make any changes in this
> file it is necessary to restart the [service] in order to get the updates. Is 
> there
> any way to implement [an automatic restart] so
> that you no longer need to use restarting the service when there are changes 
> in
> the related file in python ?

Michael already said how this *can* be implemented.

Another relevant question here is whether this *should* be implemented.
It'll certainly be very convenient during development, but I would not
recommend having this mechanism during production use.

dbus (dbus-daemon) uses inotify to automatically schedule a configuration
reload when its .conf or .service files are changed. This seemed very
attractive at the time it was implemented, but it turns out to have been
a bad idea: if a file is written, that doesn't necessarily mean it has
immediately reached its final state. In particular, a real-world service
usually consists of more than one file, and if changes are being made
to several files, it's easy to get into a situation where one file has
been updated, but a second file has not, and until the second file is
also updated the service is in a broken state.

systemd learned from dbus' mistakes here: it does not automatically reload
when its configuration or units are changed, only when it is explicitly
told to reload via the "systemctl daemon-reload" command (or equivalent),
which is done (either automatically or manually) when all files have
been written and the overall system has reached a consistent state again.

I would recommend making a production service less like dbus-daemon and
more like systemd - only reloading or restarting when a consistent state
has been reached.

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

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

[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:
> https://gitlab.gnome.org/GNOME/gvfs/-/issues/557
> 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 == usb_drive.seat:
usb_drive.do_automount()

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 login_session.seat == usb_drive.seat:
usb_drive.do_automount()
break

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 login_session.seat == usb_drive.seat:
usb_drive.do_automount()
else:
# systemd --user service, shared by all our login sessions
for login_session in this_uid.get_login_sessions():
if login_session.seat == usb_drive.seat:
usb_drive.do_automount()
break

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.

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

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

[Simon McVittie]

On Wed, 03 Mar 2021 at 13:51:38 +0100, Lennart Poettering wrote:
> On Di, 02.03.21 10:40, Carlo Wood (ca...@alinoe.com) 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:
https://developer.gnome.org/gio/stable/gio-GDBusError.html

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

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

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

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

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

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

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

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

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

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

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

Re: [systemd-devel] ssh.service in rescue.target

[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
rescue.target). 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.

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

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

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

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

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

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

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

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

[Simon McVittie]

On Thu, 27 Aug 2020 at 16:11:37 +, u...@net9.ga 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 https://xkcd.com/1638/).

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.

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

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

[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 After=network-pre.target 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 After=network-pre.target.

> > 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
https://lists.freedesktop.org/archives/systemd-devel/2020-June/044784.html
(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 After=network-pre.target
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 :-)

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

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

[Simon McVittie]

On Tue, 30 Jun 2020 at 11:27:30 +0200, Lennart Poettering wrote:
> On Sa, 27.06.20 15:54, Mark Rogers (m...@more-solutions.co.uk) wrote:
> > Adding After=network-pre.target 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 After=network-pre.target.

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
network-pre.target, 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
After=network-pre.target, 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.

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

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

[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
units.
(... 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.

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

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

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

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

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

[Simon McVittie]

On Wed, 06 May 2020 at 16:39:39 +0200, Lennart Poettering wrote:
> On Do, 16.04.20 16:56, Simon McVittie (s...@collabora.com) 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
<https://systemd.io/CONTAINER_INTERFACE/>, by giving Docker suitable
options.

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?

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

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

[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:
> 
> https://docs.netdata.cloud/packaging/docker/#run-netdata-with-the-docker-command
> https://github.com/netdata/netdata/issues/7488

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
/run/host/etc.

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
(ld.so.cache, 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
files.

/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
/run/host.

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.

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

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

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

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

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

[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
reply):

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
"/usr/share/zoneinfo/America/Gotham",
"/usr/local/share/zoneinfo/America/Gotham")
(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",
"/usr/local/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.

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

Re: [systemd-devel] dbus activation service path

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

smcv

[1] https://dbus.freedesktop.org/doc/dbus-specification.html
[2] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[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] 
> https://lists.freedesktop.org/archives/systemd-devel/2017-March/038519.html

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

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

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

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

smcv

[1] https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

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

smcv

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

Re: [systemd-devel] keyrings and dbus

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

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

Re: [systemd-devel] keyrings and dbus

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

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

Re: [systemd-devel] keyrings and dbus

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

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

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

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

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

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

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

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

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

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

smcv

[1] except for maybe backward-compatible feature enhancements where
newer versions introduce more properties
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Simon McVittie]

On Mon, 13 May 2019 at 10:38:38 +0200, Lennart Poettering wrote:
> On So, 12.05.19 13:06, Stanislav Angelovič (angelovi...@gmail.com) 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.

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

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

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

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

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

[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 http://smcv.pseudorandom.co.uk/2008/11/nonblocking/ (which was written
before the addition of sd-bus and GDBus and the deprecation of dbus-glib, but
is otherwise still relevant).

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

Re: [systemd-devel] Data flow is slow

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

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

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

[Simon McVittie]

On Fri, 28 Sep 2018 at 10:40:28 +0200, Lennart Poettering wrote:
> On Do, 27.09.18 17:17, Helmut Grohne (hel...@subdivi.de) 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
reason).

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

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

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

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

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

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

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

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

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

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

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

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

smcv

[1] up to arbitrary message size limits measured in megabytes
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

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

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

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

[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
https://enricozini.org/blog/2017/debian/qt-cross-architecture-development-in-debian/
(that's Debian armhf not Ubuntu arm64, but the principle is the same).

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

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

[Simon McVittie]

On Tue, 19 Jun 2018 at 12:32:19 +, mag...@minimum.se 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.

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

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

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

smcv

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

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

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

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

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

[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:
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/SystemWide/
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/WhatIsWrongWithSystemWide/

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

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

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

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

smcv

[1]
$ zcat minbase.tar.gz | tar -xO ./etc/passwd | grep root
root:x:0:0:root:/root:/bin/bash
$ zcat minbase.tar.gz | tar -xO ./etc/shadow | grep root
root:*:17365:0:9:7:::
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

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

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

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

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

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

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

[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".)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

From 
https://sources.debian.net/src/debian-security-support/2017.06.02/debian/debian-security-support.postinst/
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`.

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

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

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

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

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

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

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

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

[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
full root (such as CAP_SYS_ADMIN, CAP_FSETID, CAP_SETUID, CAP_SYS_MODULE,
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.

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

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

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

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

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

[Simon McVittie]

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

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

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

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

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

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

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

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

[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:
https://cgit.freedesktop.org/telepathy/telepathy-mission-control/tree/src/connectivity-monitor.c

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

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

[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
~/.config/systemd/user/default.target.wants.

I've commented on the ibus bug.

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

Re: [systemd-devel] WebUSB

[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://
> developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web )  
> (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.

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

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

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

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

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

[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,
).

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

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

[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
> DBUS_SESSION_BUS_ADDRESS to the childs?

More background on user-sessions in general:
https://lists.freedesktop.org/archives/systemd-devel/2015-January/027711.html

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.

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

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

[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
> https://wiki.debian.org/Teams/pkg-systemd/rcSMigration 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
https://bugs.freedesktop.org/show_bug.cgi?id=98254 and
https://bugs.freedesktop.org/show_bug.cgi?id=89847

Especially these comments:
https://bugs.freedesktop.org/show_bug.cgi?id=98254#c6
https://bugs.freedesktop.org/show_bug.cgi?id=98254#c8

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

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

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

[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
http://man7.org/linux/man-pages/man5/nsswitch.conf.5.html

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

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

[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. <http://www.collabora.com/>

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

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

[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
<https://github.com/jedisct1/dnscrypt-proxy/commit/f20d71fb863b6d1f4588b6b175efa9f2fd331d90>,
and maybe
<https://github.com/jedisct1/dnscrypt-proxy/commit/cdc497bb7cbb13f6dd4ad2b49ce8eeda83ea984d>
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. <http://www.collabora.com/>

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

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

[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]: basic.target: Found ordering cycle
> on basic.target/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> sockets.target/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> dnscrypt-proxy.socket/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> network.target/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> NetworkManager.service/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> dbus.service/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Found dependency on
> basic.target/start
> Jul 29 11:33:06 blablabla systemd[1]: basic.target: Breaking ordering
> cycle by deleting job sockets.target/start

You have asked systemd to do something impossible: basic.target depends
on dnscrypt-proxy.socket, which depends on network.target, which
indirectly depends on basic.target. 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 network.target 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. <http://www.collabora.com/>

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

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

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

S

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Simon McVittie]

On 01/07/16 15:44, wolfgang.wag...@riwa-gis.de 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
> basic.target/start
> Jul 01 16:09:57 postgis1 systemd[1]: Found dependency on
> sysinit.target/start
> 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
> network-online.target/start
> 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 basic.target/start
> 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 basic.target/start

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,
sysinit.target) 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 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748074> 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. <http://www.collabora.com/>

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

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

[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. <http://www.collabora.com/>

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

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

[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 gmail.com
> <http://gmail.com/>`.
...
> 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. <http://www.collabora.com/>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[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. <http://www.collabora.com/>

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

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

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

> 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. <http://www.collabora.com/>

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

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

[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
atomic-overwrite.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

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

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

[Simon McVittie]

On 07/03/16 02:46, WaLyong Cho wrote:
> As you may know, Android has properties.
> http://developer.android.com/reference/java/util/Properties.html
> 
> 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. <http://www.collabora.com/>

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

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

[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
<http://cgit.freedesktop.org/polkit/tree/src/programs/pkexec.c> 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. <http://www.collabora.com/>

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

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

[Simon McVittie]

On 12/01/16 17:51, Lennart Poettering wrote:
> On Fri, 08.01.16 17:31, Robert O'Callahan (rob...@ocallahan.org) 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 https://lkml.org/lkml/2011/8/25/124
(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. <http://www.collabora.com/>

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

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

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

    S

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

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

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

[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. <http://www.collabora.com/>

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

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

[Simon McVittie]

On 08/01/16 04:31, Robert O'Callahan wrote:
> http://rr-project.org 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
PR_SET_DUMPABLE.

See:

<http://cgit.freedesktop.org/dbus/dbus/tree/test/test-segfault.c>
<https://bugs.freedesktop.org/show_bug.cgi?id=83772>

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

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

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

[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. <http://www.collabora.com/>

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

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

[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. <http://www.collabora.com/>

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

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

[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 libdbus-1.so.3)

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

    S
-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

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

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

[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:
http://cgit.freedesktop.org/telepathy/telepathy-mission-control/tree/src/connectivity-monitor.c

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

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

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

[Simon McVittie]

On 08/10/15 21:47, Tom Gundersen wrote:
> On Mon, Sep 7, 2015 at 7:49 PM, Lubomir Rintel <lkund...@v3.sk> 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.

S

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

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

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

[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. <http://www.collabora.com/>

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