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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Full dmi/id/modalias:
dmi:bvnLENOVO:bvrB4CN29WW:bd12/04/2015:svnLENOVO:pn80HV:pvrLenovoMIIX3-1030:rvnLENOVO:rnMartini:rvrSDK0G98662WIN:cvnLENOVO:ct11:cvrLenovoMIIX3-1030:
Tested on Lenovo MIIX3 with Debian 9
Init rule variable iif oif and to, from
While foreign rules are added the network part is not attached.
attach manager to rules and use it in routing_policy_rule_free.
In general we'd leak anything that was allocated in the first parsing of
netdev, e.g. netdev name, host name, etc. Use normal netdev_unref to make sure
everything is freed.
--- command ---
/home/zbyszek/src/systemd/build2/test-network
--- stderr ---
/etc/systemd/network/wg0.netdev:3: Failed to parse netdev kind, ignoring: wireguard
/etc/systemd/network/wg0.netdev:5: Unknown section 'WireGuard'. Ignoring.
/etc/systemd/network/wg0.netdev:9: Unknown section 'WireGuardPeer'. Ignoring.
NetDev has no Kind configured in /etc/systemd/network/wg0.netdev. Ignoring
/etc/systemd/network/br0.network:13: Unknown lvalue 'NetDev' in section 'Network'
br0: netdev ready
=================================================================
==11666==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x7f3a314cf238 in __interceptor_strdup (/lib64/libasan.so.4+0x77238)
#1 0x7f3a30e71ad1 in free_and_strdup ../src/basic/string-util.c:870
#2 0x7f3a30d34fba in config_parse_ifname ../src/shared/conf-parser.c:981
#3 0x7f3a30d2f5b0 in next_assignment ../src/shared/conf-parser.c:155
#4 0x7f3a30d30303 in parse_line ../src/shared/conf-parser.c:273
#5 0x7f3a30d30dee in config_parse ../src/shared/conf-parser.c:390
#6 0x7f3a30d310a5 in config_parse_many_files ../src/shared/conf-parser.c:428
#7 0x7f3a30d3181c in config_parse_many ../src/shared/conf-parser.c:487
#8 0x55b4200f9b00 in netdev_load_one ../src/network/netdev/netdev.c:634
#9 0x55b4200fb562 in netdev_load ../src/network/netdev/netdev.c:778
#10 0x55b4200c607a in manager_load_config ../src/network/networkd-manager.c:1299
#11 0x55b4200818e0 in test_load_config ../src/network/test-network.c:128
#12 0x55b42008343b in main ../src/network/test-network.c:254
#13 0x7f3a305f8889 in __libc_start_main (/lib64/libc.so.6+0x20889)
SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
-------
Old text:
> Note that the User= and
> Group= options are not particularly useful for mount units specifying a
> "Type=" option or using configuration not specified in /etc/fstab;
> mount(8) will refuse options that are not listed in /etc/fstab if it is
> not run as UID 0.
However I recently learnt the following:
> The mount program does not read the /etc/fstab file if both device
> and dir are specified.
Therefore, if both device and dir are specified, the `user` or `users`
options in `fstab` will not have any effect. Run as a normal user,
you will always see
mount: only root can do that
Fix the explanation in the man page.
Also make sure to markup User= and Group= with <varname>.
Quoting Lennart Poettering in
https://github.com/systemd/systemd/pull/6464#issuecomment-319029293:
> If the kernel allows us to query that data we should also be Ok with passing
> it on to our own caller, regardless if selinux is technically on or off...
The advantage is that this allows gcc to be smarter and reduce linkage:
(before)$ ldd build/libnss_systemd.so.2
linux-vdso.so.1 (0x00007ffeb46ff000)
librt.so.1 => /lib64/librt.so.1 (0x00007f2f60da6000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007f2f60ba1000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f2f60978000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2f60759000)
libc.so.6 => /lib64/libc.so.6 (0x00007f2f60374000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2f61294000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f2f600f0000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f2f5feec000)
(after )$ ldd build/libnss_systemd.so.2
linux-vdso.so.1 (0x00007ffe5f543000)
librt.so.1 => /lib64/librt.so.1 (0x00007f427dcaa000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007f427daa5000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f427d886000)
libc.so.6 => /lib64/libc.so.6 (0x00007f427d4a1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f427e196000)
Note that this only works in conjuction with the previous commit: either
of the two commits alone does not have the desired effect on linkage.
Replaces #6464.
Confirmed via `udevadm test /sys/class/input/eventX` that
POINTINGSTICK_* properties were not being set for my T430s trackpoint.
After adding a local entry file (as advised in this file), the same
`udevadm test` command showed properties.
More importantly, the movement of mouse using trackpoint felt much
better. Hard to describe its previous state, but following come to mind:
slippery, hard to control, awkward. Now it feels more consistent and predictable.
A little on the sensitive side with the defaults, but didn't think it warranted
dedicated properties just for this series though as the X230 is same generation
and uses the defaults.
Before local change:
$ udevadm info /dev/input/event5
P: /devices/platform/i8042/serio1/serio2/input/input6/event5
N: input/event5
E: DEVNAME=/dev/input/event5
E: DEVPATH=/devices/platform/i8042/serio1/serio2/input/input6/event5
E: ID_BUS=i8042
E: ID_INPUT=1
E: ID_INPUT_MOUSE=1
E: ID_INPUT_POINTINGSTICK=1
E: LIBINPUT_DEVICE_GROUP=11/2/a:synaptics-pt/serio0
E: MAJOR=13
E: MINOR=69
E: SUBSYSTEM=input
E: USEC_INITIALIZED=38609915
After change:
$ udevadm info /dev/input/event5
P: /devices/platform/i8042/serio1/serio2/input/input6/event5
N: input/event5
E: DEVNAME=/dev/input/event5
E: DEVPATH=/devices/platform/i8042/serio1/serio2/input/input6/event5
E: ID_BUS=i8042
E: ID_INPUT=1
E: ID_INPUT_MOUSE=1
E: ID_INPUT_POINTINGSTICK=1
E: LIBINPUT_DEVICE_GROUP=11/2/a:synaptics-pt/serio0
E: MAJOR=13
E: MINOR=69
E: POINTINGSTICK_CONST_ACCEL=1.0
E: POINTINGSTICK_SENSITIVITY=200
E: SUBSYSTEM=input
E: USEC_INITIALIZED=38609915
same motivation as in #5816:
- distributions have scripts to rewrite shebangs on installation and
they know what locations to rely on.
- For tests/compilation we should rather rely on the user to have setup
there PATH correctly.
We need to connect to hostnamed, so a private bus connection is no good.
It'd be simpler to use the normal bus connection unconditionally, but
that'd mean that e.g. systemd-analyze set-log-level might not work in
emergency mode. So let's keep trying to use the private connection except
for "plot".
Fixes#7667.
Since systemd v236, several Arch users complained that
systemd-cryptsetup-generator exits with an OOM error and that it
prevents the boot from continuing.
Investigating the diff of cryptsetup-generator between v235 and v236 I
noticed that create_disk allowed for the `password` and `filtered`
variables to be NULL (they're handled with `strempty()`) but not their
`*_escaped` versions, and returned OOM errors in those cases.
Fix this by checking that the input string is non-NULL before deciding
that `specifier_escape` had an OOM error.
I could not test this fix myself, but some users have reported success.
Downstream bug: https://bugs.archlinux.org/task/56733
Translated taint message.
Also added a blank line before "Current system is tagged" for better
visual separation between current system state and tags description.
Up until now, the behaviour in systemd has (mostly) been to silently
ignore failures to action unit directives that refer to an unavailble
controller. The addition of AssertControlGroupController and its
conditional counterpart allow explicit specification of the desired
behaviour when such a situation occurs.
As for how this can happen, it is possible that a particular controller
is not available in the cgroup hierarchy. One possible reason for this
is that, in the running kernel, the controller simply doesn't exist --
for example, the CPU controller in cgroup v2 has only recently been
merged and was out of tree until then. Another possibility is that the
controller exists, but has been forcibly disabled by `cgroup_disable=`
on the kernel command line.
In future this will also support whatever comes out of issue #7624,
`DefaultXAccounting=never`, or similar.
Systemd services are permitted to be scripts, as well as binary
executables.
The same also applies to the underlying /sbin/mount and /sbin/swapon.
It is not necessary for the user to consider what type of program file
these are. Nor is it necessary with systemd-nspawn, to distinguish between
init as a "binary" v.s. a user-specified "program".
Also fix a couple of grammar nits in the modified sentences.
Otherwise, setting udev_log=debug in /etc/udev/udev.conf has no effects since
systemd-udevd is built with LOG_REALM=LOG_REALM_UDEV.
However using LOG_REALM_UDEV (for libudev_core) reveals another similar bug for
udevadm which should also define LOG_REALM_UDEV.
This code is executed before we parse command line/configuration
parameters, hence let's not use arg_system to figure our how to clean up
things, but instead PID == 1. Let's move that check inside of the
function, to make things a bit more robust abstract from the outside.
Also, let's add a log message about this, that was so far missing.
