Like many other recent thinkpads the factory default pointingstick
sensitivity on these devices is quite low, making the pointingstick
very slow in moving the cursor.
This extends the existing hwdb rules for tweaking the sensitivity to
also apply to the X250 models.
Like many other recent thinkpads the factory default pointingstick
sensitivity on these devices is quite low, making the pointingstick
very slow in moving the cursor.
This extends the existing hwdb rules for tweaking the sensitivity to
also apply to the T450s models.
Like many other recent thinkpads the factory default pointingstick
sensitivity on these devices is quite low, making the pointingstick
very slow in moving the cursor.
This extends the existing hwdb rules for tweaking the sensitivity to
also apply to the L450 models.
Like many other recent thinkpads the factory default pointingstick
sensitivity on these devices is quite low, making the pointingstick
very slow in moving the cursor.
This extends the existing hwdb rules for tweaking the sensitivity to
also apply to the T440p models.
"#pragma GCC optimize" is merely a convenience to decorate multiple
functions with attribute optimize. And the manual has this to say about
this attribute:
This attribute should be used for debugging purposes only. It
is not suitable in production code.
Some versions of GCC also seem to have a problem with this pragma in
combination with LTO, resulting in ICEs.
So use a different approach (indirect the memset call via a volatile
function pointer) as implemented in openssl's crypto/mem_clr.c.
Closes: #3811
systemd now returns an error when it is asked to perform disable on the
unit file path. In the past this was allowed, but systemd never really
considered an actual content of the [Install] section of the unit
file. Instead it performed disable on the unit name, i.e. purged all
symlinks pointing to the given unit file (undo of implicit link action
done by systemd when enable is called on the unit file path) and all
symlinks that have the same basename as the given unit file.
However, to notice that [Install] info of the file is not consulted one
must create additional symlinks manually. I argue that in most cases
users do not create such links. Let's be nice to our users and don't
break existing scripts that expect disable to work with the unit file
path.
Fixes#3706.
In this mode, messages from processes which are not part of the session
land in the main journal file, and only output of processes which are
properly part of the session land in the user's journal. This is
confusing, in particular because systemd-coredump runs outside of the
login session.
"Deprecate" SplitMode=login by removing it from documentation, to
discourage people from using it.
This unit acts as a dynamic "alias" target for any concrete graphical user
session like gnome-session.target; these should declare
"BindsTo=graphical-session.target" so that both targets stop and start at the
same time.
This allows services that run in a particular graphical user session (e. g.
gnome-settings-daemon.service) to declare "PartOf=graphical-session.target"
without having to know or get updated for all/new session types. This will
ensure that stopping the graphical session will stop all services which are
associated to it.
Accept both files with and without trailing newlines. Apparently some rkt
releases generated them incorrectly, missing the trailing newlines, and we
shouldn't break that.
All pending tokens are already serialized correctly and will be handled
when the mount unit is done.
Without this a 'daemon-reload' cancels all pending tokens. Any process
waiting for the mount will continue with EHOSTDOWN.
This can happen when the mount unit waits for it's dependencies, e.g.
network, devices, fsck, etc.
This is important if a job was queued for a unit but not yet started.
Without this, the job will be canceled and is never executed even though
IgnoreOnIsolate it set to 'true'.
% valgrind --leak-check=full systemctl status multipathd.service --no-pager -n0
...
==431== 16 bytes in 2 blocks are definitely lost in loss record 1 of 2
==431== at 0x4C2BBAD: malloc (vg_replace_malloc.c:299)
==431== by 0x534AF19: strdup (in /usr/lib64/libc-2.23.so)
==431== by 0x4E81AEE: free_and_strdup (string-util.c:794)
==431== by 0x4EF66C1: map_basic (bus-util.c:1030)
==431== by 0x4EF6A8E: bus_message_map_all_properties (bus-util.c:1153)
==431== by 0x120487: show_one (systemctl.c:4672)
==431== by 0x1218F3: show (systemctl.c:4990)
==431== by 0x4EC359E: dispatch_verb (verbs.c:92)
==431== by 0x12A3AE: systemctl_main (systemctl.c:7742)
==431== by 0x12B1A8: main (systemctl.c:8011)
==431==
==431== LEAK SUMMARY:
==431== definitely lost: 16 bytes in 2 blocks
This happens because map_basic() strdups the strings. Other code in systemctl
assigns strings to UnitStatusInfo without copying them, relying on the fact
that the message is longer lived than UnitStatusInfo. Add a helper function
that is similar to map_basic, but only accepts strings and does not copy them.
The alternative of continuing to use map_basic() but adding proper cleanup
to free fields in UnitStatusInfo seems less attractive because it'd require
changing a lot of code and doing a lot of more allocations for little gain.
(I put "leaking" in quotes, because systemctl is short lived anyway.)
As suggested by @mbiebl we already use the "!" special char in unit file
assignments for negation, hence we should not use it in a different context for
privileged execution. Let's use "+" instead.
To "search something", in the meaning of looking for it, is valid,
but "search _for_ something" is much more commonly used, especially when
the meaning could be confused with "looking _through_ something"
(for some other object).
(C.f. "the police search a person", "the police search for a person".)
Also reword the rest of the paragraph to avoid using "automatically"
three times.
"strict versioned dependency" suggests that version "231" of the library
is stable. But the ABI or API might be changed in any patch, so reword
the text to avoid using "version".
Not as many people use chroot as before, so make the flow a bit nicer by
talking less about chroot.
"change to the either" is awkward and unclear. Just remove that part,
because all changes are lost, period.
User expectations are broken when "systemctl enable /some/path/service.service"
behaves differently to "systemctl link ..." followed by "systemctl enable".
From user's POV, "enable" with the full path just combines the two steps into
one.
Fixes#3010.
If user isolates rescue target from multi-user or graphical target (or just
starts the service), IgnoreOnIsolate will cause issues with sulogin which is
directly started on current virtual console. This patch adds necessary
Conflicts= and Before= against rescue.service.
Note that this is not needed for emergency target, as implicit Requires= and
After= against sysinit.target is in effect for this service
(DefaultDependencies=yes).
Before this patch, a service file with ReadWriteDirectories=/file...
could fail if the file exists but is not a mountpoint, despite being
listed in /proc/self/mountinfo. It could happen with masked mounts.
Fixes https://github.com/systemd/systemd/issues/3793
Clarify that "systemctl enable" can operate either on unit names or on unit
file paths (also, adjust the --help text to clarify this). Say that "systemctl
enable" on unit file paths also links the unit into the search path.
Many other fixes.
This should improve the documentation to avoid further confusion around #3706.
