| Age | Commit message (Collapse) | Author |
|---|
|
--network-zone=
This way, they "just work", similar to --network-veth behaves, as long as
networkd is enabled and running on all involved nodes.
|
|
This adds a new concept of network "zones", which are little more than bridge
devices that are automatically managed by nspawn: when the first container
referencing a bridge is started, the bridge device is created, when the last
container referencing it is removed the bridge device is removed again. Besides
this logic --network-zone= is pretty much identical to --network-bridge=.
The usecase for this is to make it easy to run multiple related containers
(think MySQL in one and Apache in another) in a common, named virtual Ethernet
broadcast zone, that only exists as long as one of them is running, and fully
automatically managed otherwise.
|
|
Make use of this in nspawn at a couple of places. A later commit should port
more code over to this, including networkd.
|
|
networkd
|
|
Some small fixes to make it easier to run tests and fix failure in TEST-{02,08}
|
|
In this test /etc/fstab is replaced by -.mount unit. This causes
systemd-remount-fs.service to not remount / rw, which in turn causes various
failures becuase /var is not writable. In particular
systemd-tmpfiles-setup.service reports many failures. This is something
to possibly fix on its own (see https://github.com/systemd/systemd/issues/791);
in the meanwhile let's fix this test so that it doesn't fail, since the
point of the test is to check aliases on mount units, and not a ro root.
|
|
systemd-udev generated an insane amount of log output at debug level.
It would break TEST-02-CRYPTSETUP by filling the overflowing the disk
(which seems to be a bug in itself!).
|
|
|
|
It has been replaced by --state=failed.
|
|
WARNING: Image format was not specified for
'/var/tmp/systemd-test.tGi3od/rootdisk.img' and probing guessed raw.
Automatically detecting the format is dangerous for raw images, write
operations on block 0 will be restricted. Specify the 'raw' format
explicitly to remove the restrictions.
Also use unsafe caching mode, we don't care about data integrity here.
|
|
don't reopen socket fds when reloading the daemon
|
|
|
|
more dhcp fixes
|
|
Cgroup fixes.
|
|
News and other small cleanups
|
|
core: use an AF_UNIX/SOCK_DGRAM socket for cgroup agent notification
|
|
|
|
"0 units listed." is still printed.
|
|
Coverity was complaing, but it was a false positive (CID #1354669).
Nevertheless, it's better to rewrite the code so that units is never
null.
|
|
core: expose TriggerLimitIntervalUSec, dump TriggerLimitIntervalSec and TriggerLimitBurst too
|
|
Minor fixes and .po updates
|
|
|
|
|
|
|
|
|
|
Before:
$ systemctl show --property TriggerLimitIntervalSec test.socket
TriggerLimitIntervalSec=2000000
After:
$ systemctl show --property TriggerLimitIntervalUSec test.socket
TriggerLimitIntervalUSec=2s
|
|
Fixes: #3194
|
|
|
|
Make the XML validate again.
|
|
It's only relevant to DHCP, and it should be where the DUID is configured too.
|
|
|
|
|
|
Previously, we'd simply close and reopen the socket file descriptors. This is
problematic however, as we won't transition through the SOCKET_CHOWN state
then, and thus the file ownership won't be correct for the sockets.
Rework the flushing logic, and actually read any queued data from the sockets
for flushing, and accept any queued messages and disconnect them.
|
|
Previously, when the daemon was reloaded and the configuration of a socket unit
file was changed so that a different set of socket ports was defined for the
socket we'd simply reopen the socket fds not yet open. This is problematic
however, as this means the SOCKET_CHOWN state is not run for them, and thus
their UID/GID is not corrected.
With this change, don't open the missing file descriptors, but log about this
issue, and ask the user to restart the socket explicit, to make sure all
missing fds are opened.
Fixes: #3171
|
|
This should bring no behavioural change.
|
|
networkd lib: cleanup FOREACH_WORD
|
|
|
|
|
|
|
|
change trigger timeout defaults
|
|
|
|
For similar reasons as the recent addition of a limit on sessions.
Note that we don't enforce a limit on inhibitors per-user currently, but
there's an implicit one, since each inhibitor takes up one fd, and fds are
limited via RLIMIT_NOFILE, and the limit on the number of processes per user.
|
|
|
|
If we have a lot of simultaneous sessions we really shouldn't send the full
list of active sessions with each PropertyChanged message for user and seat
objects, as that can become quite substantial data, we probably shouldn't dump
on the bus on each login and logout.
Note that the global list of sessions doesn't send out changes like this
either, it only supports requesting the session list with ListSessions().
If cients want to get notified about sessions coming and going they should
subscribe to SessionNew and SessionRemoved signals, and clients generally do
that already.
This is kind of an API break, but then again the fact that this was included
was never documented.
|
|
Let's make sure we process session and inhibitor pipe fds (that signal
sessions/inhibtors going away) at a higher priority
than new bus calls that might create new sessions or inhibitors. This helps
ensuring that the number of open sessions stays minimal.
|
|
|
|
We really should put limits on all resources we manage, hence add one to the
number of concurrent sessions, too. This was previously unbounded, hence set a
relatively high limit of 8K by default.
Note that most PAM setups will actually invoke pam_systemd prefixed with "-",
so that the return code of pam_systemd is ignored, and the login attempt
succeeds anyway. On systems like this the session will be created but is not
tracked by systemd.
|
|
|
|
The unit file settings are called SocketUser= and SocketGroup= hence name these
fields that way in the "systemd-analyze dump" output too.
https://github.com/systemd/systemd/issues/3171#issuecomment-216216995
|
|
Let's lower the default values a bit, and pick different defaults for
Accept=yes and Accept=no sockets.
Fixes: #3167
|
