IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
rc-local.service acts as an ordering barrier even if its condition is
false, because conditions are evaluated when the service is about to be
started.
To avoid the ordering barrier in a legacy-free system, add a generator
to pull rc-local.service into the transaction only if the script is
executable.
If/when we rewrite SysV compatibility into a generator, this one can become
a part of it.
Both kmsg-syslogd and the real syslog service want to receive
SCM_CREDENTIALS. With socket activation it is too late to set
SO_PASSCRED in the services.
Since Linux 3.2 in order to receive SCM_CREDENTIALS it is not sufficient
to set SO_PASSCRED just before recvmsg(). The option has to be already
set when the sender sends the message.
With socket activation it is too late to set the option in the service.
It must be set on the socket right from the start.
See the kernel commit:
16e57262 af_unix: dont send SCM_CREDENTIALS by default
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=757628
DefaultStandardOutput is syslog anyway. There's no reason to assume that
the administrator would want these units to be excluded when he configures
a different DefaultStandardOutput.
This patch adds support for the Mageia Linux distribution:
http://www.mageia.org/
Mageia is a fork of Mandriva although some divergence has already occured
and thus inclusion of these changes upstream allow us to (hopefully)
migrate more rapidly to the new standard approaches systemd offers.
Indeed, we already use the preferred mechanism of OS identification via
the /etc/os-release file rather than a distro specific variation.
This patch mostly mirrors the patch added previously for Mandriva
support. In addition to those original authors, this patch was mostly
written by Dexter Morgan with help from Colin Guthrie and Eugeni Dodonov.
In order to ensure that bind mounts copy the final mount settings to the
new bind mount make the root and API FS mount options are applied before
the other file systems are mounted.
https://bugzilla.redhat.com/show_bug.cgi?id=718464
It was possible for the "ExecStartPre=-/bin/plymouth quit" to race
with plymouth-start.service which is pulled in indirectly by
basic.target -> sysinit.target.
The race left plymouth running on the terminal, making it unusable for
rescue purposes.
https://bugzilla.redhat.com/show_bug.cgi?id=710487
The mount point directory /sys/kernel/config is only created after the
module is loaded, hence there's little value in having this an automount
unit: the runtime penalty for mounting an autofs here should be the same
as for a real mount.
With output of services going to syslog by default now, the rescue shell
units need to direct their output to tty explicitly.
Specify stderr too, just in case.
remote-fs.target is ordered after the {auto,}mount units. In case of automount
we do not want to wait for the network to come up before proceeding. In case
of a regular mount unit, the unit will be ordered after network.target
so the behavior is unchanged.
This speeds up boot quite a bit for me when having some services needing
NetworkManager-wait-online.service, and having my home partition on nfs
under an automountpoint.
We don't want to fiddle around changing the RTC, not on bootup, not
on shutdown.
If we don't run NTP, we have absolutely no clue what's the current
time to store in the RTC. If we run NTP, the kernel syncs the system
time every 11 minutes to the RTC.
Especially in multi-boot environents we must not call hwclock(8)
which tries to be smart with calculating/storing/applying drifts
and such.
Live-CDs must never touch the RTC, because we don't know if it is
running in UTC or locatime.
We check for LOCAL in /etc/adjtime and if needed, ask the kernel to
apply the timezone delta to the system clock.
The very first call of settimeofday() without a time, but a timezone
warps the system clock, so that it properly runs in UTC.
Explicitly disconnect all clients from a VT when a getty starts/finishes
(requires TIOCVHANGUP, available in 2.6.29).
Explicitly deallocate getty VTs in order to flush scrollback buffer.
Explicitly reset terminals to a defined state before spawning getty.
This commit consists of the initial work to include MeeGo as a ported
distribution for systemd.
The majority of the changes are small configuration additions to auto
tools, so that MeeGo is identified as a valid distribution option.
Some small deviations will be noticed between the configuration of MeeGo
and other distributions. As MeeGo is a distribution striving for
compliancy to support its near embedded attributes and target users,
there is less user configuration options available by default. Most
services will be enabled by systemd as part of the distribution
requirements, and as such most links and service files will be pre-setup
for the MeeGo distribution. As much of this is going to be done within
the MeeGo distribution packaging this is still noteworthy to mention, as
it explains why in systemd you will observe configuration differences
where the MeeGo distribution removes all links in the pkgsysconfdir for
instance. MeeGo will be user configurable if there is desire, but most
services will be enabled by the distribution as designated by the MeeGo
compliancy standards.
Other changes are in source to add such areas as meego-release defined
in utils, and hostname in hostname-setup, defining vconsole-setup,
localizations and rescue additions as needed.
As this is all ground work, MeeGo will continue to strive for complete
compatibility.
On request of Miroslav Lichvar, rename rtc-set.target to
time-sync.target since usually the RTC chip isn't involved at all in NTP
syncs.
Also, pull it in by hwclock-load.service.
https://bugzilla.redhat.com/show_bug.cgi?id=676302
systemd now watches /run/initramfs/plymouth and generates messages
exactly when that file exists. Hence we don't need the sending of the
signals anymore.
Instead of the /dev/.run trick we have currently implemented, we decided
to move the early-boot runtime dir to /run.
An existing /var/run directory is bind-mounted to /run. If /var/run is
already a symlink, no action is taken.
An existing /var/lock directory is bind-mounted to /run/lock.
If /var/lock is already a symlink, no action is taken.
To implement the directory vs. symlink logic, we have a:
ConditionPathIsDirectory=
now, which is used in the mount units.
Skipped mount unit in case of symlink:
$ systemctl status var-run.mount
var-run.mount - Runtime Directory
Loaded: loaded (/lib/systemd/system/var-run.mount)
Active: inactive (dead)
start condition failed at Fri, 25 Mar 2011 04:51:41 +0100; 6min ago
Where: /var/run
What: /run
CGroup: name=systemd:/system/var-run.mount
The systemd rpm needs to make sure to add something like:
%pre
mkdir -p -m0755 /run >/dev/null 2>&1 || :
or it needs to be added to filesystem.rpm.
Udev -git already uses /run if that exists, and is writable at bootup.
Otherwise it falls back to the current /dev/.udev.
Dracut and plymouth need to be adopted to switch from /dev/.run to run
too.
Cheers,
Kay
Now that we have /dev/.run there's no need to use abstract namespace
sockets. So, let's move things to /dev/.run, to make things more easily
discoverable and improve compat with chroot() and fs namespacing.
During early boot, mount a tmpfs to /dev/.run and then bind mount it to
/var/run as soon as /var is available.
This makes it possible for programs involved in early boot to put
runtime data in /dev/.run which later on will show up in /var/run like
any other.
This can be used to solve the early-boot D-Bus problem: D-Bus may start
up with its socket bound to /dev/.run/dbus/system_bus_socket and after
/var it will also be available under the traditional name
/var/run/dbus/system_bus_socket.
This also is intended to be used as a better place for systemd, mount,
mdadm, blkid, plymouth, bootchart and dracut runtime data, which is
currently stored in various places in /dev/.xxx.
This merges several separate patches that I carry as part of
Mandriva systemd RPM. They touch those parts that are very
unlikely to be changed in near future and do not impose any
functionality change for systemd core. I also think it is
useful for troubleshooting to have real distribution name in
system logs, espicially when someone reports problem upstream.
The patch looks bigger than sum of replaced patches because
- previous patches were applied on top of distro=fedora, now
I need to add all those bits for distro=mandriva as well
- part of patch was done as spec file magic, but it seems more
logical to ship all these bits together
On the console indian characters cannot be displayed, hence it is
advisable to disable indian locales on the console, which most
distributions traditionally did from a shell fragment executed post
login. If getty gets started with locale settings passed it would itself
however be translated without the no-indian-on-console fixup applied.
Hence, for now don't pass any locale settings to getty/login, and thus
rely on the classic post-login script fragment to set and fix the
locale.
Eventually we probably want to drop this again since the system locale
should be read and set at one place, and not at multiple, and that one
place should be PID 1.
https://bugzilla.redhat.com/show_bug.cgi?id=663900
TERM=vt100-nav was necessary for compat with some ppc hvc devices, a
long time ago. Unfortunately vt100-nav terminfo is not installed by
default on most distros, hence change the default to v100 which is
available universally and still should be a relatively safe and
conservative default.
Should it turn out that vt100 is not really the best choice we can
revert this change again and then ask distros to move vt100-nav into
their default install.
That unity pulls in OpenRC which in turn pulls in most of legacy
system that causes lots of troubles as it is too smart, thus not
recommended.
Moreover, SystemD developers seems to agree that a service file per DM
is the best approach, so having gdm.service, kdm.service, slim.service
is better than a single wrapper for them.
