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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The list and descriptions of valid transports was difficult to read, so
break the long sentence up into discrete man page list items to improve
readability.
Since the system journal wasn't open yet, available_space() returned 0.
Before:
systemd-journal[22170]: Allowing system journal files to grow to 4.0G.
systemd-journal[22170]: Journal size currently limited to 0B due to SystemKeepFree.
After:
systemd-journal[22178]: Allowing system journal files to grow to 4.0G.
systemd-journal[22178]: Journal size currently limited to 3.0G due to SystemKeepFree.
Also, when failing to write a message, show how much space was needed:
"Failed to write entry (26 items, 260123456 bytes) despite vacuuming, ignoring: ...".
quotaon.service is already installed through dist_systemunit_DATA, so it doesn't
need to be added to nodist_systemunit_DATA. Installing the same file twice
results in a race condition where the install process can fail.
https://bugs.freedesktop.org/show_bug.cgi?id=65659
[zj: actually remove quotaon.service from the other list.]
In the following scenario:
server creates system.journal
server creates user-1000.journal
both journals share the same seqnum_id.
Then
server writes to user-1000.journal first,
and server writes to system.journal a bit later,
and everything is fine.
The server then terminates (crash, reboot, rsyslog testing,
whatever), and user-1000.journal has entries which end with
a lower seqnum than system.journal. Now
server is restarted
server opens user-1000.journal and writes entries to it...
BAM! duplicate seqnums for the same seqnum_id.
Now, we usually don't see that happen, because system.journal
is closed last, and opened first. Since usually at least one
message is written during boot and lands in the system.journal,
the seqnum is initialized from it, and is set to a number higher
than than anything found in user journals. Nevertheless, if
system.journal is corrupted and is rotated, it can happen that
an entry is written to the user journal with a seqnum that is
a duplicate with an entry found in the corrupted system.journal~.
When browsing the journal, journalctl can fall into a loop
where it tries to follow the seqnums, and tries to go the
next location by seqnum, and is transported back in time to
to the older duplicate seqnum. There is not way to find
out the maximum seqnum used in a multiple files, without
actually looking at all of them. But we don't want to do
that because it would be slow, and actually it isn't really
possible, because a file might e.g. be temporarily unaccessible.
Fix the problem by using different seqnum series for user
journals. Using the same seqnum series for rotated journals
is still fine, because we know that nothing will write
to the rotated journal anymore.
Likely related:
https://bugs.freedesktop.org/show_bug.cgi?id=64566https://bugs.freedesktop.org/show_bug.cgi?id=59856https://bugs.freedesktop.org/show_bug.cgi?id=64296https://bugs.archlinux.org/task/35581https://bugzilla.novell.com/show_bug.cgi?id=817778
Possibly related:
https://bugs.freedesktop.org/show_bug.cgi?id=64293
The order was different in various places, which makes it harder to
read to code. Also consistently use ternany for all direction checks.
Remove one free(NULL).
This allows the caller to explicitly specify which journal files
should be opened. The same functionality could be achieved before
by creating a directory and playing around with symlinks. It
is useful to debug stuff and explore the journal, and has been
requested before.
Waiting is supported, the journal will notice modifications on
the files supplied when opening the journal, but will not add
any new files.
AND term usually don't have many subterms (4 seems to be the maximum
sensible number, e.g. _BOOT_ID && _SYSTEMD_UNIT && _PID && MESSAGE_ID).
Nevertheless, the cost of checking each subterm can be relatively
high, especially when the nested terms are compound, and it
makes sense to minimize the number of checks.
Instead of looping to the end and then again over the whole list once
again after at least one term changed the offset, start the loop at
the term which caused the change. This way ½ terms in the AND match
are not checked unnecessarily again.
--user basically gives messages from your own systemd --user services.
--system basically gives messages from PID 1, kernel, and --system
services. Those two options are not exahustive, because a priviledged
user might be able to see messages from other users, and they will not
be shown with either or both of those flags.
This is the just the library part.
SD_JOURNAL_CURRENT_USER flags is added to sd_j_open(), to open
files from current user.
SD_JOURNAL_SYSTEM_ONLY is renamed to SD_JOURNAL_SYSTEM,
and changed to mean to (also) open system files. This way various
flags can be combined, which gives them nicer semantics, especially
if other ones are added later.
Backwards compatibility is kept, because SD_JOURNAL_SYSTEM_ONLY
is equivalent to SD_JOURNAL_SYSTEM if used alone, and before there
we no other flags.
$ journalctl -o verbose _EXE=/quiet/binary -f
-- Logs begin at Sun 2013-03-17 17:28:22 EDT. --
Failed to get realtime timestamp: Cannot assign requested address
JOURNAL_FOREACH_DATA_RETVAL is added, which allows the caller
to get the return value from sd_journal_enumerate_data. I think
we might want to expose this macro like SD_JOURNAL_FOREACH_DATA,
but for now it is in journal-internal.h.
There's a change in behaviour for output_*, not only in
output_verbose, that errors in sd_j_enumerate_data are not silently
ignored anymore.
https://bugs.freedesktop.org/show_bug.cgi?id=56459
When a sigchld is received from an alien child, main_pid is set to
0 then service_enter_running calls main_pid_good to check if the
child is running. This incorrectly returned true because
kill(main_pid, 0) would return >= 0.
This fixes an error where a service would die and the cgroup would
become empty but the service would still report as active (running).
In 131601349 'systemctl: align all status fields to common column',
padding was calculated for 'ListenStream: ...', etc. Later on in
45a4f7233 'systemctl: tweak output of Listen: fields a bit' output
was changed to 'Listen: ... (stream)', but calculation didn't change.
Just remove the calculation, since now the result will be always 8,
and it it more important to have everything aligned to the widest
field ("Main-PID"), than to save a few columns, usually at most two
(e.g. "Listen").
Note: strlen is more natural, and is optimized to sizeof even
with -O0.
We can assume that a service for which a watchdog timeout was triggered
is unresponsive to a clean shutdown. However, it still makes sense to
execute the post-stop cleanup commands that can be configured with
ExecStopPost=. Hence, when the timeout is hit enter STOP_SIGKILL rather
than FINAL_SIGKILL.
This is a minor fix because it's not a major issue, this fix just avoid
to get EINVAL error from sigaction(2).
There are two signals can not handled at user space, SIGKILL and
SIGSTOP even we're PID 1, trying to handle these two signals will get
EINVAL error.
There are two kinds of systemd instance, running as system manager or
user session manager, apparently, the latter is a general user space
process which can not handle SIGKILL. The special pid 1 also can not
do that refer to kernel/signal.c:do_sigaction().
However, pid 1 is unkillable because the kernel did attach
SIGNAL_UNKILLABLE to it at system boot up, refer to
init/main.c:start_kernel()
--> rest_init()
--> kernel_thread()
--> kernel_init()
--> init_post()
current->signal->flags |= SIGNAL_UNKILLABLE
With Linux 3.9 (commit a935eaecef2b209ad661dadabb4e32b7c9a9b924), the
Asus keyboard driver has changed to be more compliant to the symbol
signification. This has led to some issues with udev. In particular,
the XF86TouchpadToggle (a Fn key) does not work anymore on Asus X52J.
I found another similar patch which does not seem to have been ever
submitted/merged:
https://launchpadlibrarian.net/73337842/95-keymap.rules.patch
Find enclosed the patch containing both the launchpad patch and mine
into one file.
https://bugs.freedesktop.org/show_bug.cgi?id=65375
