man: document that shutdown() is only sometimes OK on sockets passed in via socket activation
man: fix example for DefaultEnvironment=

The example mentioned Environment= rather than DefaultEnvironment=.

Also made some other clean-ups.
update TODO
core: only attempt to connect to a session bus if one likely exists.
login: add an api to determine the slice a PID is located in to libsystemd-login
Add hasprefix macro to check prefixes of fixed length
journal: allow callers to specify OBJECT_PID=

When journald encounters a message with OBJECT_PID= set
coming from a priviledged process (UID==0), additional fields
will be added to the message:

OBJECT_UID=,
OBJECT_GID=,
OBJECT_COMM=,
OBJECT_EXE=,
OBJECT_CMDLINE=,
OBJECT_AUDIT_SESSION=,
OBJECT_AUDIT_LOGINUID=,
OBJECT_SYSTEMD_CGROUP=,
OBJECT_SYSTEMD_SESSION=,
OBJECT_SYSTEMD_OWNER_UID=,
OBJECT_SYSTEMD_UNIT= or OBJECT_SYSTEMD_USER_UNIT=.

This is for other logging daemons, like setroubleshoot, to be able to
augment their logs with data about the process.

https://bugzilla.redhat.com/show_bug.cgi?id=951627
Make sure we only show authentic coredump messages

Before we only checked the MESSAGE_ID and COREDUMP_UNIT.
Those are both user-controlled fields.

For COREDUMP_USER_UNIT, relax the rules a bit, and also
allow messages from _UID=0.
journalctl,systemctl: show messages tagged with OBJECT_SYSTEMD_[USER_]_UNIT

Replace mallocs with alloca while at it.
keymap: Apply to all Latitude and Precision models

https://launchpad.net/bugs/1193147
journald: bump the journal per-unit ratelimit defaults

Too many people kept hitting them, so let's increase the limits a bit.

https://bugzilla.redhat.com/show_bug.cgi?id=965803
tmpfiles: fix error check
update TODO
man: Fix small typo
journal-verify: allow unlinked data entries

Sometimes an entry is not successfully written, and we end up with
data items which are "unlinked", not connected to, and not used by any
entry. This will usually happen when we write to write a core dump,
and the initial small data fields are written successfully, but
the huge COREDUMP= field is not written. This situation is hard
to avoid, but the results are mostly harmless. Thus only warn about
unused data items.

Also, be more verbose about why journal files failed verification.
This should help diagnose journal failure modes without resorting
to a hexadecimal editor.

https://bugs.freedesktop.org/show_bug.cgi?id=65235 (esp. see
system.journal attached to the bug report).
libudev: Use correct type for sizeof
journal/vacuum: cleanup
journald: fix space limits reporting

Reporting of the free space was bogus, since the remaining space
was compared with the maximum allowed, instead of the current
use being compared with the maximum allowed. Simplify and fix
by reporting limits directly at the point where they are calculated.

Also, assign a UUID to the message.
journald: always vacuum empty offline files

Corrupted empty files are relatively common. I think they are created
when a coredump for a user who never logged anything before is
attempted to be written, but the write does not succeed because the
coredump is too big, but there are probably other ways to create
those, especially if the machine crashes at the right time.
Non-corrupted empty files can also happen, e.g. if a journal file is
opened, but nothing is ever successfully written to it and it is
rotated because of MaxFileSec=. Either way, each "empty" journal file
costs around 3 MB, and there's little point in keeping them around.
systemctl: conform to LSB with the "status" return code

http://fedoraproject.org/wiki/Packaging:SysVInitScript#Exit_Codes_for_the_Status_Action

https://bugzilla.redhat.com/show_bug.cgi?id=975016