| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Change-Id: Id62f08b8ecf2a909a49e5f93b2f7594b3880ef44
|
|
This reverts commit 4bc5d27b942afa83cc3d95debd2ad48d42ac07a8.
There are people somewhere that need kdbus.
Change-Id: Ib2d05f88171718c07e7de06409a1c224230e7a8d
|
|
This reverts commit a132bef0239e6c3f04096eee3a00c7ecf24a4f5c.
There are people somewhere that need kdbus.
Change-Id: I5a1f09485c524d47ef8ae53712d5fb77949bc7fa
|
|
Change-Id: Iafcca23df73f2694eda50a97771acac4b7996f30
|
|
Change-Id: If676fe909a40eadc60ee5ff023abe4ee2c64b44e
|
|
This reverts commit a2a4073acee7935040cc25380d4f51010903d9ca.
We've optimized systemd-user without unified system/session.
So, we revert the patch for unified system/session.
Change-Id: I11f6a43185aa3531c05787226a896d4a76cf2e11
|
|
start delayed.service --> finish default.target --> start all of delayed.service -->
finish delayed.target --> StartupFinished
Change-Id: I2f291ea8b5f535157eec4f105f2c37b0cea448c9
|
|
Change-Id: I56db28be6f0cecd0562ba8db6bb1d4af0b1a3b7b
|
|
Change-Id: I0527d1387500c699be0fbc319c702a77d9ae587b
|
|
The unified user session is about moving user session units, managed by
systemd --user, to main systemd, where it's managed as part of newly
created user@.target.
user@.target will contain same units as previously available in user/,
with same UID and environment setup. systemd instance is used for unit
to be able to specify UID (inherited from user@.target).
The rationale behind this work is following:
* VD requirement to remove user session support
* boot time optimization requirements, due to:
+ 'systemd --user' taking 1s its own startup that could be used for
unit startup
+ ability to better rearrange units if these managed by one systemd
instance
Unit installed by this commit will not be used till user login mechanism
will be changed in systemd package (via changing pam_systemd to start
user@.target, rather than user@.service).
Change-Id: I6c9512fda4c0c4275d78a6ca71372debc4d7e96e
|
|
This reverts commit c2d66807f77cd0607bf6d961d2cb11b64f7a97c5.
The problem was in security-config package that removed the service
file during image creation stage. The removal was caused by change
(SmackProcessLabel=) that didn't match its own "saved" policy.
Change-Id: I2680299ae1ea1920538f284a9e6c229d8b71f5c1
|
|
This reverts commit b94ec26c22938d9d83642732e3642b677bedbeb0.
Change-Id: I44c10ed7b75dc738fad7ef2df5c0ca1d50f22c1f
|
|
Change-Id: I8c0e7de59689aa83bd0273af4a66dd7a8f823ec9
|
|
Change-Id: I0ecbde7c179056840f34b05152d7dfaee48a6c0e
Signed-off-by: Hyotaek Shim <hyotaek.shim@samsung.com>
|
|
* I don't revert "unit/user@.service.m4.in (Environment=XDG_RUNTIME_DIR=/run/user/%U)
* If you want to revert this, you should add "session required pam_loginuid.so" to /etc/pam.d/systemd-user
Signed-off-by: INSUN PYO <insun.pyo@samsung.com>
Change-Id: I6f8e132eb46a150968662bc2574fdf85eb715a52
|
|
It's a long-running daemon, and it's easy to enable, hence do it.
|
|
Now that we can configure which controllers to delegate precisely, let's
limit wht we delegate to the user session: only "cpu" and "pids" as a
minimal baseline.
Fixes: #1715
|
|
An explicit --user switch is necessary because for the user@0.service instance
systemd-tmpfiles is running as root, and we need to distinguish that from
systemd-tmpfiles running in systemd-tmpfiles*.service.
Fixes #2208.
v2:
- restore "systemd-" prefix
- add systemd-tmpfiles-clean.{service,timer}, systemd-setup.service to
systemd-tmpfiles(8)
|
|
This makes sense from the point of view of the whole distribution:
if there are some specific files that have syntax problems, or unknown
users or groups, or use unsupported features, failing the whole service
is not useful.
In particular, services with tmpfiles --boot should not be started after boot.
The premise of --boot is that there are actions which are only safe to do once
during boot, because the state evolves later through other means and re-running
the boot-time setup would destroy it. If services with --boot fail in the
initial transaction, they would be re-run later on when a unit which
(indirectly) depends on them is started, causing problems.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1507501.
(If we had a mode where a service would at most run once, and would not be
started in subsequent transactions, that'd be a good additional safeguard.
Using ExecStart=-... is a bit like that, but it causes all failure to be
ignored, which is too big of a hammer.)
|
|
So far I avoided adding license headers to meson files, but they are pretty
big and important and should carry license headers like everything else.
I added my own copyright, even though other people modified those files too.
But this is mostly symbolic, so I hope that's OK.
|
|
|
|
There should be a way to turn this logic of, and DefaultDependencies=
appears to be the right option for that, hence let's downgrade this
dependency type from "implicit" to "default, and thus honour
DefaultDependencies=.
This also drops mount_get_fstype() as we only have a single user needing
this now.
A follow-up for #7076.
|
|
Fixes #7227.
|
|
Cryptsetup _netdev fixes
|
|
This way people can order units before cryptsetup-pre.target and
have them run before any cryptsetup-related stuff.
|
|
remote-cryptsetup-pre.target was designed as an active unit (that pulls in
network-online.target), the opposite of remote-fs-pre.target (a passive unit,
with individual provider services ordering itself before it and pulling it in,
for example iscsi.service and nfs-client.target).
To make remote-cryptsetup-pre.target really work, those services should be
ordered before it too. But this would require updates to all those services,
not just changes from systemd side.
But the requirements for remote-fs-pre.target and remote-cryptset-pre.target
are fairly similar (e.g. iscsi devices can certainly be used for both), so
let's reuse remote-fs-pre.target also for remote cryptsetup units. This loses
a bit of flexibility, but does away with the requirement for various provider
services to know about remote-cryptsetup-pre.target.
|
|
In the past we introduced this property just for tmp.mount. However on
todays systems usually there are many more tmpfs mounts. Most notably
mounts backing XDG_RUNTIME_DIR for each user.
Let's generalize what we already have for tmp.mount and implement the
ordering After=swap.target for all tmpfs based mounts.
|
|
This makes this target the same as remote-fs.target in this regard. In practice
it probably doesn't make that much difference, because all encrypted devices
that are part of remote-fs.target (marked with _netdev) will be used for mount
points, so they will be pulled in anyway individually, but with this change any
such device will be configured, even if it is not pulled by any other unit.
|
|
|
|
|
|
Unit dependency fixes (and cleanups)
|
|
systemd-journal-gatewayd.service (#7005)
After the discussions around #7003 I think we should restore the
User=systemd-journal-gateway line for systemd-journal-gatewayd.service,
too, so that we continue to use the state user if it exists, and create
it as dynamic user only when it does not.
Note that undoes part of a change made after 234, i.e. a never released
change.
|
|
Clean up define definitions
|
|
Let's lock things down further.
|
|
The configuration option was called -Dresolve, but the internal define
was …RESOLVED. This options governs more than just resolved itself, so
let's settle on the version without "d".
|
|
"Have" should be about the external environment and dependencies. Anything
which is a pure yes/no choice should be "enable".
|
|
The advantage is that is the name is mispellt, cpp will warn us.
$ git grep -Ee "conf.set\('(HAVE|ENABLE)_" -l|xargs sed -r -i "s/conf.set\('(HAVE|ENABLE)_/conf.set10('\1_/"
$ git grep -Ee '#ifn?def (HAVE|ENABLE)' -l|xargs sed -r -i 's/#ifdef (HAVE|ENABLE)/#if \1/; s/#ifndef (HAVE|ENABLE)/#if ! \1/;'
$ git grep -Ee 'if.*defined\(HAVE' -l|xargs sed -i -r 's/defined\((HAVE_[A-Z0-9_]*)\)/\1/g'
$ git grep -Ee 'if.*defined\(ENABLE' -l|xargs sed -i -r 's/defined\((ENABLE_[A-Z0-9_]*)\)/\1/g'
+ manual changes to meson.build
squash! build-sys: use #if Y instead of #ifdef Y everywhere
v2:
- fix incorrect setting of HAVE_LIBIDN2
|
|
(and system-update.target does not have DefaultDependencies=no)
|
|
There's a few services missing this ordering.
Also remove a duplicate Conflicts=shutdown.target from
systemd-volatile-root.service.
|
|
1. If we exited emergency mode immediately, we don't want to have an
irreversible stop job still running for syslog.socket. I _suspect_ that
can't happen, but let's not waste effort working out exactly why it's
impossible and not just very improbable.
2. Similarly, it seems undesirable to have rescue.service and
emergency.service both running with an open FD of /dev/console, for
however short a period.
|
|
Note this commit only changes how the code is expressed; it does not change
the existence of any dependency.
The `Conflicts=` was added in 3136ec90, "Stop syslog.socket when entering
emergency mode". The discussion in the issue #266 raised concerns that
this might be needed for other units, but failed to point out why
syslog.socket is special. The reason is that syslog.socket has
DefaultDepedencies=no, so it does not get Requires=sysinit.target like
other socket units do. But syslog.service does require sysinit.target,
among other things.
We don't have many socket, path, or timer units with
DefaultDependencies=no, and I don't think any of the triggered services
have such additional hard dependencies as syslog.service does.
It is much less confusing if we keep this `Conflicts=` in the same file as
the `DefaultDependencies=no` which made it necessary.
|
|
The original aim of this commit is that starting machines.target from the
rescue shell would not kill the rescue shell and lock you out of the
system.
This is similar to commit 6579a622, for the conflict between
sysinit.target and the _emergency_ shell. That particular commit
introduced an ordering cycle and will need to be reverted and/or
fixed. This one does not, because it does not need to introduce any new
dependencies.
The reason why this commit is allowable also has it's own merit:
machines.target was not marked as AllowIsolate. Also, the point of
containers is to not escape them... I don't think we want to promote
machines.target as a default target or similar; you would generally want
some system service to allow you to shut down the machine, for example. I
don't see this approach used in CoreOS, nor in Fedora Atomic Host; we are
missing any positive examples of its utility.
Requires=basic.target / After=basic.target can be removed for the same
reason.
|
|
Signed-off-by: INSUN PYO <insun.pyo@samsung.com>
Change-Id: Iaf0d6f57e6a4a124ac0301e38527bddcbb7fe679
|
|
Signed-off-by: INSUN PYO <insun.pyo@samsung.com>
Change-Id: I55a3857e1afbb6f9e583f8901a7bcaf75699fdc8
|
|
triggered (#6765)" (#6904)
This reverts commit f1e24a259ca182b6cd8a723a56da43435ce48aac. Oops.
# systemctl emergency
Failed to start emergency.target: Transaction order is cyclic. See syste...
See system logs and 'systemctl status emergency.target' for details.
# systemctl status emergency.target
● emergency.target - Emergency Mode
Loaded: loaded (/usr/lib/systemd/system/emergency.target; static; vendor preset: disabled)
Active: inactive (dead) since Mon 2017-09-25 10:43:02 BST; 2h 42min ago
Docs: man:systemd.special(7)
systemd[1]: sysinit.target: Found dependency on sysinit.target/stop
sysinit.target: Unable to break cycle starting with sysinit.target/stop
network.target: Found ordering cycle on wpa_supplicant.service/stop
network.target: Found dependency on sysinit.target/stop
network.target: Found dependency on emergency.target/start
network.target: Found dependency on emergency.service/start
network.target: Found dependency on serial-getty@ttyS0.service/stop
network.target: Found dependency on systemd-user-sessions.service/stop
network.target: Found dependency on network.target/stop
network.target: Unable to break cycle starting with network.target/stop
IMO #6509 is ugly enough that we should aim to answer it. But it could
take some time to investigate, so let's re-open the issue as a first step.
|
|
Why
---
The advantage of this is that starting sysinit.target from the emergency
shell will no longer kill the emergency shell and lock you out of the
system. Our docs already claimed that emergency.target was useful for
"starting individual units in order to continue the boot process in steps".
This resolves #6509 for my purposes.
Remaining limitation
--------------------
Starting getty.target will still kill the shell, and if you don't have a
root password you will then be locked out at that point. This is relevant
to distributions which patch the sulogin system to permit logins when the
root password is locked. Both Debian and RedHat used to follow this
behaviour! Debian have been discussing what they could replace it with at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806852
So this doesn't quite achieve perfection, but I think it's a worthwhile
change. It should be easier to understand the logic now it doesn't have
such a big hole in it. Repairing the sysinit stage of the boot is the main
reason we have emergency.target. And as discussed in the issue,
sysinit.target gets pulled in implicitly as soon as any DefaultDependencies
service is activated.
How
---
sysinit.target only needs to conflict with emergency.target. It didn't
need to conflict with emergency.service as well. In theory the conflicts
are pointless, we could just change the dependency of sysinit.target on
local-fs.target from Wants to Requires. However, doing so would mean that
when local-fs fails, the screen is flooded with yellow [DEPEND] failures.
That would hinder the poor unfortunate admin, so let's not do that.
There is no additional ordering requirement against emergency. If the
failure happens, the job for sysinit will be cancelled instantly. We don't
need to worry about when sysinit.target and its dependents would be
stopped, because sysinit waits for local-fs before it starts.
emergency.target is still necessarily stopped once we reach sysinit
(you can't express a one-way conflict in pure unit directives).
This is largely cosmetic... though perhaps it symbolizes that you're no
longer in Emergency Mode if System Initialization is successful ;-).
As a secondary advantage, the getty's which conflict on rescue.service now
need to conflict on emergency.service as well. This makes the system more
uniform and simpler to understand.
The only other effect this should have is that
`systemctl start emergency.target` is now practically the same as
`systemctl start rescue.target`. The only units this command will stop are
the conflicting getty units. Neither of those commands should ever be
used. E.g. they will not stop the gdm.service unit on Fedora 26.
|
|
add UnsetEnvironment= unit file setting, in order to fix #6407
|
|
Let's lock things down. Also, using it is the only way how to properly
test this to the fullest extent.
|
|
Now that we have UnsetEnvironment=, let's make proper use of it for
unsetting l10n settings for console gettys.
Fixes: #6407
|
|
|
