After long consideration we came to the conclusion that user
configuration in /etc should always override the (generally
computer generated) configuration in /run. User configuration
should always be what matters over anything else. Hence rearrange
the search orders accordingly. In general this should change
very little as overriding like this is seldomn done so far,
and the order between /etc and /usr stays the same.
Hi!
I was trying out the journal and the journalctl utility sometimes
crashed on me. After some debugging, I tracked it down to the fact
that next_with_matches() holds the "c" object pointer through the
journal_file_next_entry_for_data() call -- which apparently may re-map
the journal file, invalidating the pointer.
The attached patch fixes this crash for me, but being unfamiliar with
the code, I don't know if I'm doing the right thing.
This patch is also available from my github repository:
git://github.com/intgr/systemd.git
https://github.com/intgr/systemd
Regards,
Marti
For the record, here's the original stack trace at the time of remapping:
ret=0x7fff1d5cdec0) at src/journal/journal-file.c:330
ret=0x7fff1d5cdf28) at src/journal/journal-file.c:414
ret=0x7fff1d5ce0a0, offset=0x7fff1d5ce098) at
src/journal/journal-file.c:1101
i=5705, ret=0x7fff1d5ce0a0, offset=0x7fff1d5ce098) at
src/journal/journal-file.c:1147
p=6413608, data_offset=66600, direction=DIRECTION_DOWN,
ret=0x7fff1d5ce0a0, offset=0x7fff1d5ce098) at
src/journal/journal-file.c:1626
direction=DIRECTION_DOWN, ret=0x7fff1d5ce120, offset=0x7fff1d5ce128)
at src/journal/sd-journal.c:533
direction=DIRECTION_DOWN, ret=0x7fff1d5ce170, offset=0x7fff1d5ce178)
at src/journal/sd-journal.c:595
src/journal/sd-journal.c:651
From 9266fc6a58065a7c5dab67430fd78925e519dce9 Mon Sep 17 00:00:00 2001
From: Marti Raudsepp <marti@juffo.org>
Date: Fri, 9 Mar 2012 16:23:00 +0200
Subject: [PATCH] journal: Don't hold pointers to journal while remapping
This would cause a segfault otherwise.
After long consideration we came to the conclusion that user
configuration in /etc should always override the (generally computer
generated) configuration in /run. User configuration should always be
what matters over anything else. Hence rearrange the search orders
accordingly.
In general this should change very little as overriding like this is
seldomn done so far, and the order between /etc and /usr stays the same.
If a client connects to us repeatedly always using the same source port
and we instantiate a service for the incoming connection this might
clash with an old instance. Hence, include the connection number, the
same way we do it for AF_UNIX to make connections unique.
https://bugs.freedesktop.org/show_bug.cgi?id=45297
<tomegun> kay: is this a valid issue: https://bugs.archlinux.org/task/27060 ?
<kay> tomegun: udev does not really care if that fails
<tomegun> kay: the suggestion there is to treat EINVAL the same way we treat ENOTTY (i.e. as an info only)
<tomegun> if it really does not matter it might make sense to avoid bogus bug reports
<kay> tomegun: done
This device is a combination USB hub, displaylink graphics, and e2i touchscreen
Bus 001 Device 005: ID 058f:6254 Alcor Micro Corp. USB Hub
Bus 001 Device 006: ID 17e9:401a Newnham Research
Bus 001 Device 007: ID 1ac7:0001
|__ Port 1: Dev 5, If 0, Class=hub, Driver=hub/4p, 480M
|__ Port 2: Dev 6, If 0, Class=vend., Driver=udlfb, 480M
|__ Port 2: Dev 6, If 1, Class=HID, Driver=usbhid, 480M
|__ Port 3: Dev 7, If 0, Class=vend., Driver=usbtouchscreen, 12M
we need to make sure that configuration data we expose via the bus ends
up in using getting an assert(). Even though configuration data is only
parsed from trusted sources we should be more careful with what we read.
The use of identifying disks by magic byte sequences outside of the
filesystem or partion table is fragile and usually creates more
problems than it solves.
Udev-acl will be part of a future ConsoleKit release. On systemd systems,
advanced ConsoleKit and udev-acl functionality are natively provided by
systemd.
If the service reaches the start limit, mark the sockets that activate
it as failed (with the result code 'service-broken').
This way the sockets won't act as tarpits for clients connecting to
them.
This introduces the new PAM environment variable XDG_SESSION_CLASS. If
not set, defaults to "user".
This is useful for apps that want to distuingish real user logins from
"fake" ones which just exist to show a gdm login screen or a lock
screen.
The text mode welcome message will only show the distro name stored
in /etc/os-release and no longer read any distro-specific files. If
/etc/os-release does not exist, 'Linux' will be printed.
When the source tree is is ./configure'd, only /etc-os-release is read
to guess the distro to build for. If /etc/os-release does not exist,
--with-distro= needs to be specified.
A bug was introduced in acb14d3 "cgroup: when getting cgroup empty
notifications, always search up the tree".
When the given cgroup is found the hashmap, we should be happy and
return it, not go looking up the tree for another one.
Fixes the hanging NetworkManager on shutdown for me.
Avoid a bogus message from 'systemctl enable ...' when all units given
are SysV services:
Warning: unit files do not carry install information. No operation
executed.
https://bugzilla.redhat.com/show_bug.cgi?id=787407
This keeps behavior in line calling /sbin/modprobe -- aliases will be
resolved to the relevant modules, and errors from inserting modules
which are already loaded are ignored.
Fixes segfault in systemd-logind, triggered by:
systemd-loginctl show-session $XDG_SESSION_ID.
Bug introduced by d200735e13,
so only systemd v39 is affected.
Currently remote mounts automatically get:
After=remote-fs-pre.target network.target
remote-fs-pre.target is already After=network.target. Just make sure
remote-fs-pre.target is pulled in by remote-fs.target if any remote
filesystems are configured.
For the mount units it is then sufficient to get:
After=remote-fs-pre.target
Later NetworkManager will hook its NM-wait-online.service into
remote-fs-pre.target.wants in order to remove the need for the administrator
to enable the service manually when he has any remote filesystems.
https://bugzilla.redhat.com/show_bug.cgi?id=787314
The reaping of generator processes run as part of a daemon-reload should not
call waitid(PID_ALL). The waitid() call in execute_directory() is intended only
to reap the executed processes, but if a service process exits at about the
same time as a daemon-reload, then that service process is reaped as well,
preventing it from being reaped in the proper place in
manager_dispatch_sigchld().
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=43625
The assumption that the initial job is the job with id==1 is incorrect.
Some jobs may be enqueued before the job that starts the default unit as
in this example:
-.mount changed dead -> mounted
Trying to enqueue job quotacheck.service/start/fail
Installed new job quotacheck.service/start as 1
Installed new job systemd-stdout-syslog-bridge.socket/start as 2
Enqueued job quotacheck.service/start as 1
Trying to enqueue job quotaon.service/start/fail
Installed new job quotaon.service/start as 5
Enqueued job quotaon.service/start as 5
Activating default unit: default.target
Trying to enqueue job graphical.target/start/replace
This fixes a bug where displaying of boot status messages was turned off
too early.
Immediately after forking off a process change the comm name and argv[0]
to "(foobar)" where "foobar" is the basename of the path we are about to
execute.
This should be useful when charting boot progress.
This patch adds WatchdogTimestamp[Monotonic] to the systemd service
D-Bus API. The timestamp is updated to the current time when the
service calls 'sd_nofity("WATCHDOG=1\n")'.
Using a timestamp instead of an 'alive' flag has two advantages:
1. No timeout is needed to define when a service is no longer alive.
This simplifies both configuration (no timeout value) and
implementation (no timeout event).
2. It is more robust. A 'dead' service might not be detected should
systemd 'forget' to reset an 'alive' flag. It is much less likely
to get a valid new timestamp if a service died.
Apparently the perfomance price for compression is to steep to apply it
for all objects >= 64 and < 512 in size, as measured by Arjan Van De
Ven, hence increase the threshold to 512 which yields better results.
We need to tell the X server to grab the keyboards
and mice associated with a hotplugged seat, so that
it doesn't have the ability to control the kernel
vt consoles.
Udev does no longer automatically create udev rules in /etc from the
device hotplug path.
No device name reservation will happen anymore; this model creates
too many problems for setups with many device changes or media which
is booted on different hardware.
Enumerated device names which are based on device discovery order or
on persistent on-disk name reservation will in general not be supported
by udev in the future. It is a problem that can not be solved properly,
and it always creates new problems at the same time it tries to solve
the original one. Udev will no longer pretend it can solve these issues,
and people should switch to available alternatives which provide the
far better compromise.
From now on, udev will only create /dev/cdrom for the first optical
drive, and if the drive is capable /dev/dvd. No other devices will
get any compatibility symlinks or enumerated device names like cdrom1,
cdrom2, and so on. The /dev/cdrom and /dev/dvd links have by default
a negative link priority, which will cause them to be overwritten by
any other device which clains the same names with already existing
udev rules.
If stable device names are needed, the /dev/disk/by-id/ links, which
uniquely identify a specific piece of hardware should be used. The links
usually contain a device serial number and the link names will not depend
on device discovery order.
If completely identical devices with identical or no serial number
need to be handled at the same time, the /dev/disk/by-path/ links can
be used. These links depend on the physical port which is used to connect
the device. It will change when the same device is moved to a different
port or host adapter.
If custom names are needed, custom udev rules which match on specific
device properties need to be added by the administrator.
When systemd starts, plymouth may be already displaying progress
graphically. Do not switch the console to text mode at that time.
All other users of reset_terminal_fd() do the switch as before.
This avoids a graphical glitch with plymouth, especially visible with
vesafb, but could be also seen as a sub-second blink with radeon.
https://bugzilla.redhat.com/show_bug.cgi?id=785548
Device nodes might have been deleted again by the kernel before an
'add' or 'change' event is even started. We need to run all rules,
regardless of the state in /dev.
Tom Gundersen noticed a regression where comment=systemd.automount in
fstab no longer prevented the adding of the After=foo.mount dependency
into local-fs.target. He bisected it to commit 9ddc4a26.
It turns out that clearing the default_dependencies flag is necessary
after all, in order to avoid complementing of Wants= with After= in the
target unit. We still want to add the dependencies on quota units and
umount.target though.
In preparation for https://bugzilla.gnome.org/show_bug.cgi?id=655380 we
decided it's better to include the multi-seat X wrapper in systemd,
rather than gdm. (Side effect: this makes this accessible for other
DMs)
This is a stop-gap for now, until X gins proper multi-seat graphics
support at which point this code will go away without replacement.
When we read the 'uevent' file we need to make sure, that we do not
read the relative DEVNAME= path provided by the kernel and overwrite
the absolute path udev expects here.
Hi,
during the builds for Fedora/s390x I've found that systemd v38 fails to
build on big-endian platforms.
...
make[2]: Entering directory `/root/systemd'
CC src/journal/libsystemd_journal_la-sd-journal.lo
src/journal/sd-journal.c: In function 'init_location':
src/journal/sd-journal.c:69:22: error: incompatible types when
initializing type 'long unsigned int' using type 'sd_id128_t'
src/journal/sd-journal.c:69:20: error: incompatible types when assigning
to type 'sd_id128_t' from type 'long unsigned int'
make[2]: *** [src/journal/libsystemd_journal_la-sd-journal.lo] Error 1
I see the problem in using le64toh() on the 16 bytes boot_id structure
in init_location()
Please see
http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=544375 for a
full build log and attachment for a proposed fix.
With regards
Dan
Albert Strasheim reported a socket unit with Accept=yes was failing
sometimes.
getpeername() returns ENOTCONN if the connection was killed by TCP RST.
The socket unit must not fail when it happens.
Reproducer available at:
https://bugzilla.redhat.com/show_bug.cgi?id=783344
Since the addition of ControlGroupPersistent, systemd is trivially
killed by "systemctl status any.service".
bus_property_append_bool must not be used for a tri-state int.
Also, should it really "b", or do we want the tri-state nature to be seen?
For now just comment out the buggy DBus property.
The pid file watch could outlive the service unit if a daemon-reload
request came at the right time. The inotify event would then be
delivered to who knows where.
Fix it by unwatching in the service destructor.
Further changes will be needed to preserve the state of the pid file
watch across daemon-reload. For now let's just fix the crash observed
by Jóhann Guðmundsson:
Assertion 's->state == SERVICE_START || s->state == SERVICE_START_POST'
failed at src/service.c:2609, function service_fd_event(). Aborting
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=783118
