summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* meson: allow setting the version string during configurationZbigniew Jędrzejewski-Szmek2018-12-213-1/+11
| | | | | | This will be useful when building distro packages, because we can set the version string to the rpm/dpkg/whatever version string, and getter reports from end users.
* meson-vcs-tag: add work-around for git bugZbigniew Jędrzejewski-Szmek2018-12-212-3/+6
|
* meson: generate version tag from gitZbigniew Jędrzejewski-Szmek2018-12-2119-22/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | $ build/systemctl --version systemd 239-3555-g6178cbb5b5 +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN +PCRE2 default-hierarchy=hybrid $ git tag v240 -m 'v240' $ ninja -C build ninja: Entering directory `build' [76/76] Linking target fuzz-unit-file. $ build/systemctl --version systemd 240 +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN +PCRE2 default-hierarchy=hybrid This is very useful during development, because a precise version string is embedded in the build product and displayed during boot, so we don't have to guess answers for questions like "did I just boot the latest version or the one from before?". This change creates an overhead for "noop" builds. On my laptop, 'ninja -C build' that does nothing goes from 0.1 to 0.5 s. It would be nice to avoid this, but I think that <1 s is still acceptable. Fixes #7183. PACKAGE_VERSION is renamed to GIT_VERSION, to make it obvious that this is the more dynamically changing version string. Why save to a file? It would be easy to generate the version tag using run_command(), but we want to go through a file so that stuff gets rebuilt when this file changes. If we just defined an variable in meson, ninja wouldn't know it needs to rebuild things.
* udev: modernize ctrl_send and use PROJECT_VERSIONZbigniew Jędrzejewski-Szmek2018-12-211-31/+19
| | | | | | | | | | | | | | PROJECT_VERSION is used in preparation for future changes. Let's simplify the code by using structured initialization. If the string written to .version ever became to long, the compiler will truncate it and tell us: ../src/udev/udev-ctrl.c: In function ‘ctrl_send’: ../src/udev/udev-ctrl.c:221:28: warning: initializer-string for array of chars is too long .version = "udev-" STRINGIFY(R_VERSION), ^~~~~~~ ../src/udev/udev-ctrl.c:221:28: note: (near initialization for ‘ctrl_msg_wire.version’) No functional change.
* meson: define PROJECT_VERSION as the "bare" project versionZbigniew Jędrzejewski-Szmek2018-12-207-10/+11
| | | | | | | | | | | | | | Let's not use atoi() if we can simply provide the project version as a number. In C code, this is the numerical project version. In substitutions in other files, this is just the bare substitution. The "PACKAGE_" prefix is from autotools, and is strange. We call systemd a "project", and "package" is something that distros build. Let's rename. PACKAGE_URL is renamed to PROJECT_URL for the same reasons and for consistency. (This leave PACKAGE_VERSION as the stringified define for C code.)
* Remove use of PACKAGE_STRINGZbigniew Jędrzejewski-Szmek2018-12-194-5/+4
| | | | | | | PACKAGE_VERSION is more explicit, and also, we don't pretend that changing the project name in meson.build has any real effect. "systemd" is embedded in a thousand different places, so let's just use the hardcoded string consistently. This is mostly in preparation for future changes.
* mount: disable mount-storm protection while mount unit is starting.NeilBrown2018-12-192-1/+25
| | | | | | | | | | | | | | | | | The starting of mount units requires that changes to /proc/self/mountinfo be processed before the SIGCHILD from the completion of /sbin/mount is processed, as described by the comment /* Note that due to the io event priority logic, we can be sure the new mountinfo is loaded * before we process the SIGCHLD for the mount command. */ The recently-added mount-storm protection can defeat this as it will sometimes deliberately delay processing of /proc/self/mountinfo. So we need to disable mount-storm protection when a mount unit is starting. We do this by keeping a counter of the number of pending mounts, and disabling the protection when this is non-zero. Thanks to @asavah for finding and reporting this problem.
* Merge pull request #11201 from keszybz/more-newsLennart Poettering2018-12-181-0/+20
|\ | | | | Some git history rewriting and more news
| * NEWS: add a note about symlink following in .wants and .requiresZbigniew Jędrzejewski-Szmek2018-12-181-0/+13
| | | | | | | | | | | | This ain't so easy to express without using too much technical language... https://github.com/systemd/systemd/pull/10094#issuecomment-427407570
| * NEWS: add note about NNP=yesZbigniew Jędrzejewski-Szmek2018-12-181-0/+7
| |
| * units: set NoNewPrivileges= for all long-running servicesLennart Poettering2018-12-1815-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously, setting this option by default was problematic due to SELinux (as this would also prohibit the transition from PID1's label to the service's label). However, this restriction has since been lifted, hence let's start making use of this universally in our services. On SELinux system this change should be synchronized with a policy update that ensures that NNP-ful transitions from init_t to service labels is permitted. Fixes: #1219
| * units: sort [Service] sections alphabeticallyLennart Poettering2018-12-1815-171/+171
| |
| * Revert "units: set NoNewPrivileges= for all long-running services"Zbigniew Jędrzejewski-Szmek2018-12-1815-186/+171
| | | | | | | | | | | | | | | | | | This reverts commit 3ca9940cb95cb263c6bfe5cfee72df232fe46a94. Let's split the commit in two: the sorting and the changes. Because there's a requirement to update selinux policy, this change is incompatible, strictly speaking. I expect that distributions might want to revert this particular change. Let's make it easy.
* | Merge pull request #11182 from poettering/fileio-more-paranoiaLennart Poettering2018-12-188-136/+177
|\ \ | | | | | | More safety checks for fileio.c
| * | test-fileio: test safe_fgetc directlyZbigniew Jędrzejewski-Szmek2018-12-181-2/+30
| | | | | | | | | | | | | | | Non-ascii chars are used so that we get both "positive" and "negative" characters (on the arches where char is signed).
| * | update TODOLennart Poettering2018-12-181-26/+1
| | |
| * | process-util: rework getenv_for_pid() to use read_nul_string()Lennart Poettering2018-12-181-19/+16
| | |
| * | test: add test case for read_nul_string()Lennart Poettering2018-12-181-0/+35
| | |
| * | fileio: let's minimize 'count' inc/dec callsLennart Poettering2018-12-181-4/+3
| | | | | | | | | | | | | | | instead of increasing it and immediately after decreasing it again, let's just increase it a bit later.
| * | fileio: replace read_nul_string() by read_line() with a special flagLennart Poettering2018-12-183-53/+27
| | | | | | | | | | | | | | | | | | | | | read_line() is a lot more careful and optimized than read_nul_string() but does mostly the same thing. let's replace the latter by the former, just with a special flag that toggles between the slightly different EOL rules if both.
| * | process-util: make get_process_environ() saferLennart Poettering2018-12-181-10/+17
| | | | | | | | | | | | Let's add a size limit, and let's use safe_fgetc().
| * | tree-wide: port some code over to safe_fgetc()Lennart Poettering2018-12-183-23/+20
| | |
| * | fileio: add new safe_fgetc() helper callLennart Poettering2018-12-182-0/+29
| | | | | | | | | | | | | | | We have very similar code whenever we call fgetc() in place, let's replae it by a common implementation.
* | | Merge pull request #11203 from keszybz/json-no-slash-escapingChris Down2018-12-181-4/+0
|\ \ \ | |/ / |/| | json: do not unescape slashes
| * | json: do not unescape slashesZbigniew Jędrzejewski-Szmek2018-12-181-4/+0
|/ / | | | | | | | | | | | | | | | | | | Apparently this originated in PHP, so the json output could be directly embedded in HTML script tags. See https://stackoverflow.com/questions/1580647/json-why-are-forward-slashes-escaped. Since the output of our tools is not intended directly for web page generation, let's not do this unescaping. If needed, the consumer can always do escaping as appropriate for the target format.
* | Merge pull request #10221 from lucaswerkmeister/bash-completionZbigniew Jędrzejewski-Szmek2018-12-181-0/+11
|\ \ | | | | | | | | | | | | Merged locally to resolve a conflict. The redirection of error is required to suppress "# Not showing unlisted system calls, ...".
| * | bash-completion: analyze: complete system call setsLucas Werkmeister2018-09-301-0/+11
| | |
* | | Merge pull request #11197 from keszybz/various-fixupsLennart Poettering2018-12-185-10/+21
|\ \ \ | | | | | | | | Various fixups
| * | | test-mountpoint-util: more debug infoZbigniew Jędrzejewski-Szmek2018-12-181-4/+14
| | | |
| * | | meson: print EFI CC configuration nicelyZbigniew Jędrzejewski-Szmek2018-12-181-1/+1
| | | | | | | | | | | | | | | | | | | | In 595343fb4c99c2679d347ef7c19debfbfed6342e it was converted to an array. This doesn't look good in the output. Let's convert it back to a string.
| * | | meson: rename two more variables from _c to _sourcesZbigniew Jędrzejewski-Szmek2018-12-182-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _c is misleading because .h files should be included in those lists too (this tells meson that the build outputs should be rebuilt if the header files change). Follow-up for 1437822638ff9468fa78c7cfe56f8f55f955a61d.
| * | | systemctl: add comment why whitespace in message is neededZbigniew Jędrzejewski-Szmek2018-12-181-1/+2
| | | |
* | | | Merge pull request #11191 from poettering/hashmap-clearLennart Poettering2018-12-187-46/+263
|\ \ \ \ | |_|_|/ |/| | | rework hashmap_clear()
| * | | test-hashmap: add test to compare hashmap_free performanceZbigniew Jędrzejewski-Szmek2018-12-182-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The point here is to compare speed of hashmap_destroy with free and a different freeing function, to the implementation details of hashmap_clear can be evaluated. Results: current code: /* test_hashmap_free (slow, 1048576 entries) */ string_hash_ops test took 2.494499s custom_free_hash_ops test took 2.640449s string_hash_ops test took 2.287734s custom_free_hash_ops test took 2.557632s string_hash_ops test took 2.299791s custom_free_hash_ops test took 2.586975s string_hash_ops test took 2.314099s custom_free_hash_ops test took 2.589327s string_hash_ops test took 2.319137s custom_free_hash_ops test took 2.584038s code with a patch which restores the "fast path" using: for (idx = skip_free_buckets(h, 0); idx != IDX_NIL; idx = skip_free_buckets(h, idx + 1)) in the case where both free_key and free_value are either free or NULL: /* test_hashmap_free (slow, 1048576 entries) */ string_hash_ops test took 2.347013s custom_free_hash_ops test took 2.585104s string_hash_ops test took 2.311583s custom_free_hash_ops test took 2.578388s string_hash_ops test took 2.283658s custom_free_hash_ops test took 2.621675s string_hash_ops test took 2.334675s custom_free_hash_ops test took 2.601568s So the test is noisy, but there clearly is no significant difference with the "fast path" restored. I'm surprised by this, but it shows that the current "safe" implementation does not cause a performance loss. When the code is compiled with optimization, those times are significantly lower (e.g. 1.1s and 1.4s), but again, there is no difference with the "fast path" restored. The difference between string_hash_ops and custom_free_hash_ops is the additional cost of global modification and the extra function call.
| * | | test-hashmap: use the usual function headers and print timing statsZbigniew Jędrzejewski-Szmek2018-12-182-32/+48
| | | | | | | | | | | | | | | | This makes it slightly easier to watch for performance changes.
| * | | hashmap: use ternary op to shorten codeZbigniew Jędrzejewski-Szmek2018-12-182-2/+2
| | | |
| * | | lldp: add test coverage for sd_lldp_get_neighbors() with multiple neighborsFilipe Brandenburger2018-12-181-0/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In particular, check that the order of the results is consistent. This test coverage will be useful in order to refactor the compare_func used while sorting the results. When introduced, this test also uncovered a memory leak in sd_lldp_stop(), which was then fixed by a separate commit using a specialized function as destructor of the LLDP Hashmap. Tested: $ ninja -C build/ test $ valgrind --leak-check=full build/test-lldp
| * | | sd-lldp: accept if a neighbor is already removed from the hashtableLennart Poettering2018-12-181-1/+6
| | | |
| * | | hashmap: rework hashmap_clear() to be more defensiveLennart Poettering2018-12-182-11/+19
| | | | | | | | | | | | | | | | | | | | | | | | Let's first remove an item from the hashmap and only then destroy it. This makes sure that destructor functions can mdoify the hashtables in their own codee and we won't be confused by that.
* | | | Merge pull request #11200 from poettering/mailmap-updates-240Zbigniew Jędrzejewski-Szmek2018-12-182-175/+218
|\ \ \ \ | | | | | | | | | | updates for .mailmap and NEWS
| * | | | NEWS: add one more itemLennart Poettering2018-12-181-0/+11
| | | | |
| * | | | NEWS: update contributors list, taking new .mailmap into accountLennart Poettering2018-12-181-39/+40
| | | | |
| * | | | sort .mailmap alphabeticallyLennart Poettering2018-12-181-165/+165
| | | | |
| * | | | update .mailmap a bit from v240 contributionsLennart Poettering2018-12-181-0/+31
| |/ / /
* | | | Merge pull request #11194 from poettering/resolved-soa-parentLennart Poettering2018-12-181-6/+14
|\ \ \ \ | |/ / / |/| | | be more conservative with set of RRs to authenticate
| * | | resolved: mention which RRs we query when requesting them to authenticate ↵Lennart Poettering2018-12-181-6/+6
| | | | | | | | | | | | | | | | some other RR
| * | | resolved: only attempt non-answer SOA RRs if they are parents of our queryLennart Poettering2018-12-181-0/+8
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no value in authenticating SOA RRs that are neither answer to our question nor parent of our question (the latter being relevant so that we have a TTL from the SOA field for negative caching of the actual query). By being to eager here, and trying to authenticate too much we run the risk of creating cyclic deps between our transactions which then causes the over-all authentication to fail. Fixes: #9771
* | | timesync: fix serialization of IP addressLennart Poettering2018-12-181-1/+5
| | | | | | | | | | | | Fixes: #11169
* | | NEWS: document the usern/mknod borkage in 4.18 a bitLennart Poettering2018-12-171-0/+28
| | |
* | | NEWS: add missing 'not'Lennart Poettering2018-12-171-1/+1
| | |
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-04 07:03:24 +0100