| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
We already have tolower() calls there, hence let's unify this at one place.
Also, update the code to only use ASCII operations, so that we don't end up
being locale dependant.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
service is running
This adds a new boolean setting DynamicUser= to service files. If set, a new
user will be allocated dynamically when the unit is started, and released when
it is stopped. The user ID is allocated from the range 61184..65519. The user
will not be added to /etc/passwd (but an NSS module to be added later should
make it show up in getent passwd).
For now, care should be taken that the service writes no files to disk, since
this might result in files owned by UIDs that might get assigned dynamically to
a different service later on. Later patches will tighten sandboxing in order to
ensure that this cannot happen, except for a few selected directories.
A simple way to test this is:
elogind-run -p DynamicUser=1 /bin/sleep 99999
|
|
|
|
|
|
|
| |
This way we can reuse them for validating User=/Group= settings in unit files
(to be added in a later commit).
Also, add some tests for them.
|
|
|
|
|
| |
Similar to MemoryMax=, MemorySwapMax= limits swap usage. This controls
controls "memory.swap.max" attribute in unified cgroup.
|
|
|
|
|
| |
- define CLONE_NEWCGROUP
- add fun to detect whether cgroup namespaces are supported
|
|
|
|
|
|
|
| |
This reverts commit aac7c5ed8bc6ffaba417b9c0b87bcf342865431b. This
visibility bug originated in ld.gold and has been fixed upstream:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5417c94d1a944d1a27f99240e5d62a6d7cd324f1
|
|\
| |
| | |
V231 stable
|
| | |
|
| | |
|
|\|
| |
| | |
Merge dev_v231 into master
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
This option can be used, if elogind is built while a different cgroup
controller than planned is active.
A valid scenario could be a gentoo user switching from systemd to
openrc+elogind.
|
| |
| |
| |
| |
| |
| |
| | |
It is not needed to ask for authorization to put the system to sleep.
Such a system is most commonly a single-user laptop, and no user,
especially me, wants to enter the root password after hitting the
suspend key. ;-)
|
| |
| |
| |
| |
| |
| | |
elogind only calls this when shutting down, rebooting or cancelling a
pending shutdown/reboot. Authorization is already needed there, so do
not question the user twice, just because they forgot to sudo.
|
| | |
|
| |
| |
| |
| | |
debug mode, even if it was started from a tty.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
the system fails.
|
| |
| |
| |
| | |
failed.
|
| | |
|
| | |
|
| |
| |
| |
| | |
isn't working.
|
| |
| |
| |
| | |
cancelling a pending shutdown/reboot
|
| |
| |
| |
| | |
allow extra wall messages.
|
| | |
|
| |
| |
| |
| | |
the show anyway.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Do not do anything in manager_setup_wall_message_timer() if wall
messages are disabled anyway.
- Set up a wall timer in any case there is time left. The original
sources would not even set up a timer if the next messages would
be now. As time is measured in USEC, that's pretty rare, but
possible.
- If less than 1 Second is left to the first message, delay it.
- systemd would print out a message at once, if less than 15 minutes
are left to the event. Do this only, if the next scheduled message
wouldn't come within the next 3 seconds, or it might come to
awkward double messages.
|
| |
| |
| |
| |
| |
| |
| |
| | |
It is perfectly valid to have NULL modes. The default configuration
for suspend to ram is such a case.
Having NULL states doesn't make any sense other than no suspension is
possible any more. But a user might have set any *State value to an
empty string, so better assume (and assert) nothing here.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This method is called from a systemd manager that is the system
instance to inform all user instances of systemd about the pending
cgroup release.
elogind on the other hand is always there just once. And the release
of cgroups is handled by the local cgroups manager, which should be
provided by the running init system.
Even if there is no cgroup management, so elogind sets itself up as
a small cgroups manager itself, there aren't any user instances that
could react on the forwarding anyway.
|
| |
| |
| |
| |
| |
| | |
Support for kdbus can no longer be enabled or disabled. It is simply
there and will be used if needed and possible.
So if you have kdbus available, elogind might use it.
|
| | |
|
| |
| |
| |
| | |
libelogind-shared.
|
| | |
|
| |
| |
| |
| | |
of printf.h
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(#5271)
The code make the following assertion: when freeing a event loop object
(usually it's done after exiting from the main event loop), no signal events
are still queued and are pending.
This assertion can be found in event_unmask_signal_data() with
"assert(!d->current);" assertion.
It appears that this assertion can be wrong at least in a specific case
described below.
Consider the following example which is inspired from udev: a process defines 3
source events: 2 are created by sd_event_add_signal() and 1 is created by
sd_event_add_post().
1. the process receives the 2 signals consecutively so that signal 'A' source
event is queued and pending. Consequently the post source event is also
queued and pending. This is done by sd_event_wait().
2. The callback for signal 'A' is called by sd_event_dispatch().
3. The next call to sd_event_wait() will queue signal 'B' source event.
4. The callback for the post source event is called and calls sd_event_exit().
5. the event loop is exited.
6. freeing the event loop object will lead to the assertion failure in
event_unmask_signal_data().
This patch simply removes this assertion as it doesn't seem to be a
bug if the signal data still reference a signal source at this point.
(cherry picked from commit 4470860388e12a5dda1d65773e411a349221a3e9)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes:
$ ./libtool --mode execute valgrind --leak-check=full ./journalctl >/dev/null
==22309== Memcheck, a memory error detector
==22309== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==22309== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==22309== Command: /home/vagrant/elogind/.libs/lt-journalctl
==22309==
Hint: You are currently not seeing messages from other users and the system.
Users in groups 'adm', 'elogind-journal', 'wheel' can see all messages.
Pass -q to turn off this notice.
==22309==
==22309== HEAP SUMMARY:
==22309== in use at exit: 8,680 bytes in 4 blocks
==22309== total heap usage: 5,543 allocs, 5,539 frees, 9,045,618 bytes allocated
==22309==
==22309== 488 (56 direct, 432 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 4
==22309== at 0x4C2BBAD: malloc (vg_replace_malloc.c:299)
==22309== by 0x6F37A0A: __new_var_obj_p (__libobj.c:36)
==22309== by 0x6F362F7: __acl_init_obj (acl_init.c:28)
==22309== by 0x6F37731: __acl_from_xattr (__acl_from_xattr.c:54)
==22309== by 0x6F36087: acl_get_file (acl_get_file.c:69)
==22309== by 0x4F15752: acl_search_groups (acl-util.c:172)
==22309== by 0x113A1E: access_check_var_log_journal (journalctl.c:1836)
==22309== by 0x113D8D: access_check (journalctl.c:1889)
==22309== by 0x115681: main (journalctl.c:2236)
==22309==
==22309== LEAK SUMMARY:
==22309== definitely lost: 56 bytes in 1 blocks
==22309== indirectly lost: 432 bytes in 1 blocks
==22309== possibly lost: 0 bytes in 0 blocks
==22309== still reachable: 8,192 bytes in 2 blocks
==22309== suppressed: 0 bytes in 0 blocks
(cherry picked from commit 29d87223d54fc13e16f444677f0a94ed0755bd88)
|
| |
| |
| |
| |
| | |
Fixes: #4431
(cherry picked from commit 84a4e6608dbda38c724ab196a226db209a50b224)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When started by the kernel, we are connected to the console, and we'll set TERM
properly to some value in fixup_environment(). We'll then enable or disable
colors based on the value of $SYSTEMD_COLORS and $TERM.
When reexecuting, TERM should be already set, so we can use this value.
Effectively, behaviour is the same as before affd7ed1a was reverted, but instead
of reopening the console before configuring color output, we just ignore what
stdout is connected to and decide based on the variables only.
(cherry picked from commit 158fbf7661912adf0f42c93155499119811dde82)
|
| |
| |
| |
| |
| |
| | |
Follow-up for #3924.
(cherry picked from commit 05b2a8fd7a0533758d2f532df798cabc3c442683)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 8121f4d209eca85dcb11830800483cdfafbef9b7.
The special 'key handling' inhibitors should always work regardless of
any *IgnoreInhibited settings – otherwise they're nearly useless.
Reverts: #3470
Fixes: #3897
(cherry picked from commit 06a70b918d4d753769a727239f75af8896006467)
|
| |
| |
| |
| |
| |
| |
| | |
config_parse_user_tasks_max() was incorrectly accepting percentage value
between 1 and 99. Update it to accept 0% and 100%. This brings it in line
with TasksMax handling in elogind.
(cherry picked from commit cb3e4417590196bd30e1b8097348dca6ba34bd15)
|