The generator paths are internal implementation details, they should not
be documented explicitly.
We should document where private user units are found however.
Stop importing non-sensical kernel-exported variables. All
parameters in the kernel command line are exported to the
initial environment of PID1, but suppressed if they are
recognized by kernel built-in code. The EFI booted kernel
will add further kernel-internal things which do not belong
into userspace.
The passed original environ data of the process is not touched
and preserved across re-execution, to allow external reading of
/proc/self/environ for process properties like container*=.
In case of scripts, _EXE is set to the interpreter name, and
_COMM is set based on the file name. Add a match for _COMM,
and _EXE if the interpreter is not a link (e.g. for yum,
the interpreter is /usr/bin/python, but it is a link to
/usr/bin/python2, which in turn is a link to /usr/bin/python2.7,
at least on Fedora, so we end up with _EXE=/usr/bin/python2.7).
I don't think that such link chasing makes sense, because
the final _EXE name is more likely to change.
src/python-systemd/_reader.c: In function Reader_get_catalog:
src/python-systemd/_reader.c:912:53: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
assert(mid_len > l);
^
Python 2.7, and 3.2 and higher support querying compilation
flags through pkg-config. This makes python support follow
rules similar to various other optional compilation-time
libraries. New flags are called PYTHON_DEVEL_CFLAGS and
PYTHON_DEVEL_LIBS, because PYTHON (without _DEVEL), is
already used for the python binary name, and things would
be confusing if the same prefix was used for two things.
configure has --disable-python-devel to disable python modules.
One advantage is that CFLAGS for modules gets smaller:
- -I/usr/include/python3.3m -I/usr/include/python3.3m -Wno-unused-result -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv
+ -I/usr/include/python3.3m
as does LIBS:
- -lpthread -ldl -lutil -lm -lpython3.3m
+ -lpython3.3m
Support for Python 2.6 is removed, but can be easily
restored by using
PYTHON_DEVEL_CFLAGS="$(python2.6-config --cflags)",
etc., as ./configure parameters.
https://bugs.freedesktop.org/show_bug.cgi?id=57800
"systemctl load" has always been racy since the GC could hit any time,
before making use of the loaded unit. Very recent systemd will run GC
immeidately after all unit state changes which has the effect that the
the effect of "systemctl load" is completely gone now, so let's remove
the support for it in "systemctl" for good.
"systemctl set-log-level" is a command for analysis and tracing hence
"systemd-analyze" should be the better home for it, thus allowing us to
make the overly large "systemctl" a bit smaller.
It's an analysis command and its format is explicitly not covered by any
stability guarantees, hence move away from systemctl and into
systemd-analyze, minimizing the already large interface of systemctl a
bit.
This patch also adds auto-paging to the various systemd-analyze commands
where that makes sense
Previously, the logging sockets were asynchronous and if clogged we'd
lose messages. We did this to be extra careful given that PID 1 might
need to spawn the logging daemon as response to PID 1's own log messages
and we really should avoid a deadlock in that case.
As it turns out this causes loss of too many messages, hence make the
socket blocking again, however put a time limit on it to avoid unbounded
deadlocks in the unlikely case they happen.
https://bugs.freedesktop.org/show_bug.cgi?id=66664
Without this, tmpfiles-setpu-dev would be re-run if any other service,
which pulls in basic.target, was started after setup-dev was finished
and before basic.target was active.
On Sat, Jul 20, 2013 at 12:56 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> After a recent change present in 3.11-rc1 there is a driver, called processor,
> that can be bound to the CPU devices whose sysfs directories are located under
> /sys/devices/system/cpu/. A side effect of this is that, after the driver has
> been bound to those devices, the kernel adds DRIVER=processor to ENV for CPU
> uevents and they don't match the default rule for autoloading modules matching
> MODALIAS:
>
> DRIVER!="?*", ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod load $env{MODALIAS}"
>
> any more. However, there are some modules whose module aliases match specific
> CPU features through the modalias string and those modules should be loaded
> automatically if a compatible CPU is present. Yet, with the processor driver
> bound to the CPU devices the above rule is not sufficient for that, so we need
> a new default udev rule allowing those modules to be autoloaded even if the
> CPU devices have drivers.
Yesterday I added test-suite.log as dependency to the .PRECIOUS
target. Automake is warning about this target being redefined
and from what I see there is no way I can stop the warning but
I can add the %MAKEFILE% as dependency.
automake warning:
Makefile.am:35: warning: user target '.PRECIOUS' defined here ...
/usr/share/automake-1.13/am/configure.am: ... overrides Automake target '.PRECIOUS' defined here
[zj: s/%MAKEFILE%/Makefile/ because %MAKEFILE% wasn't actually substituted properly.]
