The qmi-proxy/mbim-proxy processes spawned by the daemon live in the
service's cgroup, so with the default KillMode=control-group systemd
sends SIGTERM to them at the same time as to the daemon on every unit
stop. The proxy exits immediately, tearing the control channel from
under the daemon while it is still disabling the modems:
<msg> caught signal, shutting down...
<msg> [modem0] state changed (connected -> disabling)
<msg> [modem0] port 'cdc-wdm0' no longer controllable, reprobing
<wrn> [/dev/cdc-wdm0] MBIM error: Device must be open to send commands
<wrn> shutdown failed: timeout waiting for sleep preparation to complete
The consequences of losing the proxy mid-shutdown:
- the modem disable/disconnect never reaches the device, so an MBIM
session with an active bearer is left open in the firmware (observed
to occasionally wedge the MBIM function of a Sierra EM7565 until a
firmware reset);
- the port teardown stalls waiting on the dead proxy until the
shutdown timeout, so stopping the unit always takes the full
MAX_SHUTDOWN_TIME_SECS instead of a second or two;
- the port invalidation triggers the device reprobe path in the middle
of the shutdown.
With KillMode=mixed only the daemon receives SIGTERM; the proxies
survive long enough for a clean disconnect and MBIM/QMI close, and
whatever remains in the cgroup afterwards (an idle, stateless proxy) is
killed when the unit finally stops.
Signed-off-by: Semyon Maryasin <simeon@maryasin.name>
This assumes the needed modem hardware is typically not available
inside containers. If however, the local admin configures the container
to get access to the hardware in question, ModemManager can be
instructed to run in that specific container by doing:
`sudo systemctl edit ModemManager.service`
Then entering the following text in the editor:
[Unit]
# Remove condition of "not container"
ConditionVirtualization=
Upon saving/exiting, ModemManager can then be started with:
`sudo systemctl start ModemManager.service`
Signed-off-by: Simon Deziel <simon@sdeziel.info>
With the recently added support for modems using QRTR, ModemManager
needs to have access to the corresponding address family so it can
interact with the modem.
Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
GVfs' libgvfsdbus.so GIo module, when automatically loaded, attempts to
discover if there's a session D-Bus instance to use. It tries real hard
to get the socket name it would use -- in absence of XDG_RUNTIME_DIR it
decides to make it up with user's home directory. When HOME is unset
too, it just tries to figure it out by looking into /etc/passwd. Which
upsets SELinux that would better not see us looking into it.
We trigger the load of the GIo modules, by using the GFile API to access
the the ports in /dev. They're utterly uesless to us, but there doesn't
seem to be a way to disable their load. Oh well.
For now, let's just ensure HOME is set and the problematic path in glib
is not taken.
syslog implementations are using socket activation nowadays, so an
explicit ordering is not necessary anymore. Plus, syslog.target was
already dropped from systemd in v198.
Reported-by: Michael Biebl <biebl@debian.org>
What's left enabled:
* Access to /dev -- obviously
* CAP_SYS_ADMIN -- this is needed by TIOCSSERIAL only. Too bad this also
allows TIOCSTI, which allows for code injection unless something else
(SELinux) disallows access to ttys with shells.
Maybe kernel should use CAP_SYS_TTY_CONFIG for this.
* socket(AF_NETLINK) -- udev & kernel device changes
* socket(AF_UNIX) -- D-Bus
This reverts commit 91898aa8b0.
See additional comments in the following bug:
https://bugzilla.gnome.org/show_bug.cgi?id=701229
Basically, 'mask' and 'unmask' operations are not the ones we should be using
or suggesting; and the Alias= for the DBus file is the correct way to go.
Avoid setting up the Alias rule, which was a helper to let us 'disable' the
systemd service including dbus-activations. Without the Alias, 'disable' will
still let starting ModemManager through dbus-activation. If you really want to
fully disallow starting MM also through dbus-activation, you should 'mask' and
'unmask' the service.
E.g.:
$ sudo systemctl mask ModemManager
ln -s '/dev/null' '/etc/systemd/system/ModemManager.service'
$ sudo mmcli -L
error: couldn't find the ModemManager process in the bus
$ sudo systemctl unmask ModemManager
rm '/etc/systemd/system/ModemManager.service'
$ sudo mmcli -L
No modems were found
https://bugzilla.gnome.org/show_bug.cgi?id=701229
Semyon Maryasin
Simon Deziel
Arnaud Ferraris
Undef
Aleksander Morgado
Lubomir Rintel
Aleksander Morgado