Re: [systemd-devel] clarification on daemon-reload

Le lundi 18 mai 2015, 07:51:18 Igor Bukanov a écrit : > What I would like to know is what is the exact behavior of systemctl > daemon-reload. I am writing a service that creates/modifies other > units by placing files under /run and I would like to know what are > the limitations. In my case I cann

Re: [systemd-devel] [PATCH 6/6] zsh-completion: make the arrays _sys_active_units, _sys_startable_units and _sys_restartable_units local to the completer.

Patchset imported to github. Pull request: -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list

Re: [systemd-devel] clarification on daemon-reload

On 18 May 2015 at 05:35, Andrei Borzenkov wrote: > > > What exactly do you mean? It has RefuseManualStart set? I meant that, for example, A is enabled and contains Requires=B and this is the only dependency that causes B to run and then B alters or even disables A and calls systemctl daemon-reloa

[systemd-devel] [PATCH 1/6] zsh-completion: actually run _filter_units_by_property when creating the arrays _sys_(re|)startable_units

--- shell-completion/zsh/_systemctl.in | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/shell-completion/zsh/_systemctl.in b/shell-completion/zsh/_systemctl.in index cce9dea..8764e07 100644 --- a/shell-completion/zsh/_systemctl.in +++ b/shell-completion/zsh/_systemctl.

[systemd-devel] [PATCH 3/6] zsh-completion: less forking in _systemctl_get_template_names()

--- shell-completion/zsh/_systemctl.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/shell-completion/zsh/_systemctl.in b/shell-completion/zsh/_systemctl.in index f30fb84..5a39cfb 100644 --- a/shell-completion/zsh/_systemctl.in +++ b/shell-completion/zsh/_systemctl.in @@ -14

[systemd-devel] [PATCH 4/6] zsh-completion: less forking in _systemctl_failed_units() and make the array `_sys_failed_units' local to the completer.

--- shell-completion/zsh/_systemctl.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/shell-completion/zsh/_systemctl.in b/shell-completion/zsh/_systemctl.in index 5a39cfb..a4db563 100644 --- a/shell-completion/zsh/_systemctl.in +++ b/shell-completion/zsh/_systemctl.in @@

[systemd-devel] [PATCH 2/6] zsh-completion: actually complete template names for subcommands enable, reenable and disable.

compadd's -a option treats non-option arguments as arrays. So $(_systemctl_get_template_names) expands to some words that aren't legal array names. Even if there were, they would be empty; thus adding nothing. deduplicated a few functions too. --- shell-completion/zsh/_systemctl.in | 21 +

[systemd-devel] [PATCH 5/6] zsh-completion: removing more pointless forks

--- shell-completion/zsh/_systemctl.in | 28 +--- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/shell-completion/zsh/_systemctl.in b/shell-completion/zsh/_systemctl.in index a4db563..d2ebab0 100644 --- a/shell-completion/zsh/_systemctl.in +++ b/shell-comp

[systemd-devel] [PATCH 6/6] zsh-completion: make the arrays _sys_active_units, _sys_startable_units and _sys_restartable_units local to the completer.

--- shell-completion/zsh/_systemctl.in | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/shell-completion/zsh/_systemctl.in b/shell-completion/zsh/_systemctl.in index d2ebab0..9b7f962 100644 --- a/shell-completion/zsh/_systemctl.in +++ b/shell-completion/zsh/_systemctl.i

Re: [systemd-devel] dev-root.device is not active, results in an umount spree

Lennart Poettering [2015-05-17 18:06 +0200]: > More specifically, they should follow the second item in the > "Execution Environment" section: pre-mount /sys read-only in the > container. That's the default indeed, but you can configure it otherwise. While that might be questionable, it's just one

Re: [systemd-devel] clarification on daemon-reload

В Sun, 17 May 2015 10:06:28 +0200 Igor Bukanov пишет: > Hello, > > suppose a unit B runs just because another unit A contains Requires=B and What exactly do you mean? It has RefuseManualStart set? > After=B. When B runs, it changes A like adding new dependencies, altering > Exec command etc an

Re: [systemd-devel] dev-root.device is not active, results in an umount spree

On Sun, 17.05.15 13:02, Martin Pitt (martin.p...@ubuntu.com) wrote: > Hey Lennart, > > Lennart Poettering [2015-05-14 18:09 +0200]: > > > As I mentioned before, simply ignoring /dev/root doesn't help in all > > > cases, and hardcoding it in the code is a bit ugly. > > > > It doesn't help in all

Re: [systemd-devel] systemd-nspawn trouble

2015-05-15 22:16 GMT+02:00 Tom Gundersen : > on-demand I agree with Lennart that it makes the most sense to simply > unconditionally load the modules. If this is undesirable the solution > should be to teach the kernel to auto-load the modules, not to expect > the admin to figure out that explicit

Re: [systemd-devel] [PATCH v2] dev-root.device is not active, results in an umount spree

Patchset imported to github. Pull request: -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@

[systemd-devel] [PATCH v2] dev-root.device is not active, results in an umount spree

Hello again, Martin Pitt [2015-05-17 13:02 +0200]: > - Alternative: Fix device_found_node() to create a .device with the > correct ("tentative") state if the device doesn't exist in /dev/ > or udev (yet). Then manager_load_unit() would not create a "dead" > stub .device any more, but

Re: [systemd-devel] Automatic user ACL management

On Sun, 17 May 2015 15:00:11 +0200 Martin Pitt wrote: > Mikhail Morfikov [2015-05-17 12:46 +0200]: > > As you can read, for instance here > > ( > > http://enotty.pipebreaker.pl/2012/05/23/linux-automatic-user-acl-management/ > > ), logind, which is a part of systemd, can set permissions to some

Re: [systemd-devel] Automatic user ACL management

Mikhail Morfikov [2015-05-17 12:46 +0200]: > As you can read, for instance here > ( http://enotty.pipebreaker.pl/2012/05/23/linux-automatic-user-acl-management/ > ), logind, which is a part of systemd, can set permissions to some > devices for user sessions. There's also a vid showing how this kind

Re: [systemd-devel] Automatic user ACL management

Am 17.05.2015 um 14:20 schrieb Mikhail Morfikov: On Sun, 17 May 2015 12:55:18 +0200 Reindl Harald wrote: Am 17.05.2015 um 12:46 schrieb Mikhail Morfikov: Is that possible? I'm asking because I often listen to the music and I don't really need my monitor to be on most of the time, so I just l

Re: [systemd-devel] Automatic user ACL management

On Sun, 17 May 2015 12:55:18 +0200 Reindl Harald wrote: > > > Am 17.05.2015 um 12:46 schrieb Mikhail Morfikov: > > Is that possible? I'm asking because I often listen to the music > > and I don't really need my monitor to be on most of the time, so I > > just lock the screen. But when I lock th

Re: [systemd-devel] dev-root.device is not active, results in an umount spree

Hey Lennart, Lennart Poettering [2015-05-14 18:09 +0200]: > > As I mentioned before, simply ignoring /dev/root doesn't help in all > > cases, and hardcoding it in the code is a bit ugly. > > It doesn't help in all cases? Which ones? Can you elaborate? It doesn't seem to help at all in e. g. LXC.

Re: [systemd-devel] Automatic user ACL management

Am 17.05.2015 um 12:46 schrieb Mikhail Morfikov: Is that possible? I'm asking because I often listen to the music and I don't really need my monitor to be on most of the time, so I just lock the screen. But when I lock the screen, the active session becomes inactive and amarok stops playing. An

[systemd-devel] Automatic user ACL management

As you can read, for instance here ( http://enotty.pipebreaker.pl/2012/05/23/linux-automatic-user-acl-management/ ), logind, which is a part of systemd, can set permissions to some devices for user sessions. There's also a vid showing how this kind of behavior works in practice ( https://www.youtub

Re: [systemd-devel] Reduce unit-loading time

Hello cee, cee1 [2015-05-16 0:46 +0800]: > Thanks for the suggestion, it was other processes running in parallel > which presumably consuming lots of IO, after sending SIGSTOP at the > first (and SIGCONT later), the unit loading time is decreased to > ~100ms. You probably want to use some readah

[systemd-devel] clarification on daemon-reload

Hello, suppose a unit B runs just because another unit A contains Requires=B and After=B. When B runs, it changes A like adding new dependencies, altering Exec command etc and then B calls systemctl daemon-reload. Then the systemd uses the new definition for A, right? In particular, if according