Re: [systemd-devel] [systemd-commits] src/timesync
On Wed, 04.02.15 17:09, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
On Wed, Feb 04, 2015 at 08:06:44AM -0800, Lennart Poettering wrote:
src/timesync/timesyncd-manager.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
New commits:
commit 7e3254b3bae19221afefdb87b61ff92c755fd2f4
Author: Lennart Poettering lenn...@poettering.net
Date: Wed Feb 4 17:00:23 2015 +0100
timesyncd: downgrade more log messages from LOG_INFO to LOG_DEBUG
https://bugs.freedesktop.org/show_bug.cgi?id=87505
Let's make timesyncd less chatty.
diff --git a/src/timesync/timesyncd-manager.c
b/src/timesync/timesyncd-manager.c
index d3c62c9..223671c 100644
--- a/src/timesync/timesyncd-manager.c
+++ b/src/timesync/timesyncd-manager.c
@@ -285,7 +285,7 @@ static int manager_clock_watch(sd_event_source *source,
int fd, uint32_t revents
}
/* resync */
-log_info(System time changed. Resyncing.);
+log_debug(System time changed. Resyncing.);
m-poll_resync = true;
return manager_send_request(m);
@@ -740,7 +740,7 @@ static int manager_begin(Manager *m) {
m-poll_interval_usec = NTP_POLL_INTERVAL_MIN_SEC *
USEC_PER_SEC;
server_address_pretty(m-current_server_address, pretty);
-log_info(Using NTP server %s (%s)., strna(pretty),
m-current_server_name-string);
+log_debug(Using NTP server %s (%s)., strna(pretty),
m-current_server_name-string);
sd_notifyf(false, STATUS=Using Time Server %s (%s).,
strna(pretty), m-current_server_name-string);
Hm, but isn't the problem elsewhere? The bug report stated that ipv6
router advertisements cause timesyncd to resync, spamming the time servers.
Indeed. Reopened.
Not sure what the right approach here is though...
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] src/timesync
On Wed, Feb 04, 2015 at 06:24:13PM +0100, Lennart Poettering wrote:
On Wed, 04.02.15 18:18, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
On Wed, Feb 04, 2015 at 06:10:40PM +0100, Lennart Poettering wrote:
On Wed, 04.02.15 17:09, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
wrote:
On Wed, Feb 04, 2015 at 08:06:44AM -0800, Lennart Poettering wrote:
src/timesync/timesyncd-manager.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
New commits:
commit 7e3254b3bae19221afefdb87b61ff92c755fd2f4
Author: Lennart Poettering lenn...@poettering.net
Date: Wed Feb 4 17:00:23 2015 +0100
timesyncd: downgrade more log messages from LOG_INFO to LOG_DEBUG
https://bugs.freedesktop.org/show_bug.cgi?id=87505
Let's make timesyncd less chatty.
diff --git a/src/timesync/timesyncd-manager.c
b/src/timesync/timesyncd-manager.c
index d3c62c9..223671c 100644
--- a/src/timesync/timesyncd-manager.c
+++ b/src/timesync/timesyncd-manager.c
@@ -285,7 +285,7 @@ static int manager_clock_watch(sd_event_source
*source, int fd, uint32_t revents
}
/* resync */
-log_info(System time changed. Resyncing.);
+log_debug(System time changed. Resyncing.);
m-poll_resync = true;
return manager_send_request(m);
@@ -740,7 +740,7 @@ static int manager_begin(Manager *m) {
m-poll_interval_usec = NTP_POLL_INTERVAL_MIN_SEC *
USEC_PER_SEC;
server_address_pretty(m-current_server_address, pretty);
-log_info(Using NTP server %s (%s)., strna(pretty),
m-current_server_name-string);
+log_debug(Using NTP server %s (%s)., strna(pretty),
m-current_server_name-string);
sd_notifyf(false, STATUS=Using Time Server %s (%s).,
strna(pretty), m-current_server_name-string);
Hm, but isn't the problem elsewhere? The bug report stated that ipv6
router advertisements cause timesyncd to resync, spamming the time
servers.
Indeed. Reopened.
Not sure what the right approach here is though...
Maybe we should just set a flag and ignore network changes until the
normal time for the next sync comes, if we were already sucessfully
synced.
Hmm, what about this:
- If we managed to get a successful sync, don't act on the event, just
wait for the next normal resync
That's what I meant.
- If we did not manage to get a successful sync, try again
immediately, but not any more often than once per 10s or so...
I think we should fall back here too, maybe more slowly. In case we can't
connect, we shouldn't spam the network too much.
I think this should make the thing pretty robust and responsive to
network changes when necessary, but not flood the network needlessly?
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsckd daemon for inter-fsckd communication
On Wed, Feb 04, 2015 at 05:50:29PM +0100, Didier Roche wrote:
Le 04/02/2015 17:24, Zbigniew Jędrzejewski-Szmek a écrit :
Thanks again for the quick review! Fixed if not commented (sorry,
some issues were back due to the refactoring).
On Wed, Feb 04, 2015 at 05:06:45PM +0100, Didier Roche wrote:
+typedef struct Clients {
+struct Manager *manager;
+int fd;
+dev_t devnum;
+size_t cur;
+size_t max;
+int pass;
+double percent;
+size_t buflen;
+
+LIST_FIELDS(struct Clients, clients);
+} Clients;
Would be better to call this Client.
+typedef struct Manager {
+sd_event *event;
+Clients *clients;
But still 'Client *clients' here.
Right, I can't decide (due to the list) what's the best one, what do
you think?
We use singular in other cases like this.
+if (!client)
+return log_oom();
+client-fd = new_client_fd;
+client-manager = m;
+LIST_PREPEND(clients, m-clients, client);
+r = sd_event_add_io(m-event, NULL, client-fd, EPOLLIN,
progress_handler, client);
+if (r 0) {
+remove_client((m-clients), client);
+return r;
+}
I think you can do this in opposite order, and then the clean-up will
not be necessary.
I need to delete the client item and close the new fd (which is part
of remove_client()), and I can't assign the add_io event before the
client instantiated. So, it will be another free() + safe_close()
rather then remove_client(). Does it makes sense still to add this?
I guess no.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] Add sd_event_loop_timeout to sd_event
Le 04/02/2015 17:10, Lennart Poettering a écrit : On Wed, 04.02.15 17:05, Didier Roche (didro...@ubuntu.com) wrote: Hey, I rewrote a version of this patch including the feedback on the list. As per IRC discussion, (and after giving up the busy loop for a rewrite with epool), I did rebase it again on sd_event. I'm only proposing there up for review the 2 first patches (without plymouth communication, cancel support, i18n, man pages and the service and socket) so that I don't have to rebase all other 10 patches on a moving ground. Tom just added support for installing timer events with a NULL callback, that trigger event loop exit. I kinda prefer that solution over a new call sd_event_loop() with timeout. sd_event_add_time(event, NULL, CLOCK_MONOTONIC, now(CLOCK_MONOTONIC) + 5 * USEC_PER_SEC, NULL, NULL); So, it means that I need to reset it after any received activity, is that ok? (as this will be really frequent as each clients in parallel can send a message each 50ms). The goal is to have a global inactivity timeout. I didn't see a way to cancel this event source though? Didier That line should be enough to mak an even loop exit after 5s... Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]
Lennart Poettering [2015-02-04 16:38 +0100]: Sure, I can only recommend again: in the the glue code that calls out to systemctl from service, you can add the code to use --no-block or --job-mode=ignore-dependencies , if you notice you are in shutdown mode... Yeah, I agree that given all the options that's the best heuristics for now. Modern code, that talks directly to systemctl, that uses hook scripts, should always use --no-block for these cases. Yeah, for sure. We just don't have that luxury easily, as first these scripts don't call systemctl but service (for the Debianists: or invoke-rc.d, but same difference), it will take some time to find all these occurrences, and people will hate us for having to add stuff like if (running under systemd) systemctl --no-block reload foo else service foo reload I am not proposing anything like that. Right, this was just a reply to modern code that talks directly to systemctl, and we can't do that while we support more than one init system. Sorry for the misunderstanding. - Don't enqueue a reload if the service to be reloaded isn't running. E. g. postfix.service inactive/dead in https://bugs.debian.org/635777 or smbd.service start/waiting in https://launchpad.net/bugs/1417010. This would completely avoid the deadlock in most situations already, and doesn't change the semantics for working use cases either, so this should even be applicable for upstream? For the record, this was already discussed here: http://lists.freedesktop.org/archives/systemd-devel/2014-July/021457.html continuation: http://lists.freedesktop.org/archives/systemd-devel/2014-August/022048.html I mean, if you want precise sysv semantics you can just use --job-mode=ignore-dependencies always, since sysv ignore all deps too when sysv scripts are involved. Always sounds rather unsafe to me, as we would totally ignore a unit's Requires/Wants= then. Doing it if !systemctl is-system-running sounds ok. I'd strongly encourage you to work around this on client side in the sysv glue, not breaking the guarantess that systemd-aware code needs when issuing commands. Yes, I prefer that as well. (That's what I meant with distro side..) Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] src/timesync
On Wed, Feb 04, 2015 at 08:06:44AM -0800, Lennart Poettering wrote:
src/timesync/timesyncd-manager.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
New commits:
commit 7e3254b3bae19221afefdb87b61ff92c755fd2f4
Author: Lennart Poettering lenn...@poettering.net
Date: Wed Feb 4 17:00:23 2015 +0100
timesyncd: downgrade more log messages from LOG_INFO to LOG_DEBUG
https://bugs.freedesktop.org/show_bug.cgi?id=87505
Let's make timesyncd less chatty.
diff --git a/src/timesync/timesyncd-manager.c
b/src/timesync/timesyncd-manager.c
index d3c62c9..223671c 100644
--- a/src/timesync/timesyncd-manager.c
+++ b/src/timesync/timesyncd-manager.c
@@ -285,7 +285,7 @@ static int manager_clock_watch(sd_event_source *source,
int fd, uint32_t revents
}
/* resync */
-log_info(System time changed. Resyncing.);
+log_debug(System time changed. Resyncing.);
m-poll_resync = true;
return manager_send_request(m);
@@ -740,7 +740,7 @@ static int manager_begin(Manager *m) {
m-poll_interval_usec = NTP_POLL_INTERVAL_MIN_SEC *
USEC_PER_SEC;
server_address_pretty(m-current_server_address, pretty);
-log_info(Using NTP server %s (%s)., strna(pretty),
m-current_server_name-string);
+log_debug(Using NTP server %s (%s)., strna(pretty),
m-current_server_name-string);
sd_notifyf(false, STATUS=Using Time Server %s (%s).,
strna(pretty), m-current_server_name-string);
Hm, but isn't the problem elsewhere? The bug report stated that ipv6
router advertisements cause timesyncd to resync, spamming the time servers.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsckd daemon for inter-fsckd communication
Le 04/02/2015 17:24, Zbigniew Jędrzejewski-Szmek a écrit :
Thanks again for the quick review! Fixed if not commented (sorry, some
issues were back due to the refactoring).
On Wed, Feb 04, 2015 at 05:06:45PM +0100, Didier Roche wrote:
+typedef struct Clients {
+struct Manager *manager;
+int fd;
+dev_t devnum;
+size_t cur;
+size_t max;
+int pass;
+double percent;
+size_t buflen;
+
+LIST_FIELDS(struct Clients, clients);
+} Clients;
Would be better to call this Client.
+typedef struct Manager {
+sd_event *event;
+Clients *clients;
But still 'Client *clients' here.
Right, I can't decide (due to the list) what's the best one, what do you
think?
+if (!client)
+return log_oom();
+client-fd = new_client_fd;
+client-manager = m;
+LIST_PREPEND(clients, m-clients, client);
+r = sd_event_add_io(m-event, NULL, client-fd, EPOLLIN,
progress_handler, client);
+if (r 0) {
+remove_client((m-clients), client);
+return r;
+}
I think you can do this in opposite order, and then the clean-up will
not be necessary.
I need to delete the client item and close the new fd (which is part of
remove_client()), and I can't assign the add_io event before the client
instantiated. So, it will be another free() + safe_close() rather then
remove_client(). Does it makes sense still to add this?
+typedef struct FsckProgress {
+dev_t devnum;
+unsigned long cur;
+unsigned long max;
+int pass;
+} FsckProgress;
I think I asked about that before, but not 100% sure: shouldn't those be size_t?
If they are disk offsets, than long is not enough.
Sorry, I only changed it in fsckd.c and fsck.c, done in the passing
struct now.
Cheers,
Didier
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] hwdb: Bind toolbox buttons to the Windows key
One would expect pressing the button to go to an overview / show applications mode, we thus map it to leftmeta, the Windows key. See https://bugzilla.gnome.org/show_bug.cgi?id=658602#c17 --- hwdb/60-keyboard.hwdb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hwdb/60-keyboard.hwdb b/hwdb/60-keyboard.hwdb index 56fbbb1..94f36d9 100644 --- a/hwdb/60-keyboard.hwdb +++ b/hwdb/60-keyboard.hwdb @@ -590,7 +590,7 @@ keyboard:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*:pvrThinkPad*X2*Tablet* # ThinkPad X6 Tablet keyboard:dmi:bvn*:bvr*:bd*:svnLENOVO*:pnThinkPad*X6*:pvr* KEYBOARD_KEY_6c=direction # rotate - KEYBOARD_KEY_68=f13# toolbox + KEYBOARD_KEY_68=leftmeta # toolbox KEYBOARD_KEY_6b=esc# escape KEYBOARD_KEY_6d=right # right on d-pad KEYBOARD_KEY_6e=left # left on d-pad @@ -601,7 +601,7 @@ keyboard:dmi:bvn*:bvr*:bd*:svnLENOVO*:pnThinkPad*X6*:pvr* # ThinkPad X41 Tablet keyboard:dmi:bvn*:bvr*:bd*:svnIBM*:pn18666TU:pvr* KEYBOARD_KEY_6c=direction # rotate - KEYBOARD_KEY_68=f13# toolbox + KEYBOARD_KEY_68=leftmeta # toolbox KEYBOARD_KEY_6b=esc# escape KEYBOARD_KEY_69=enter # enter on d-pad -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] Add sd_event_loop_timeout to sd_event
On Wed, 04.02.15 17:05, Didier Roche (didro...@ubuntu.com) wrote: Hey, I rewrote a version of this patch including the feedback on the list. As per IRC discussion, (and after giving up the busy loop for a rewrite with epool), I did rebase it again on sd_event. I'm only proposing there up for review the 2 first patches (without plymouth communication, cancel support, i18n, man pages and the service and socket) so that I don't have to rebase all other 10 patches on a moving ground. Tom just added support for installing timer events with a NULL callback, that trigger event loop exit. I kinda prefer that solution over a new call sd_event_loop() with timeout. sd_event_add_time(event, NULL, CLOCK_MONOTONIC, now(CLOCK_MONOTONIC) + 5 * USEC_PER_SEC, NULL, NULL); That line should be enough to mak an even loop exit after 5s... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] fsckd daemon for inter-fsckd communication
On Wed, Feb 04, 2015 at 05:06:45PM +0100, Didier Roche wrote:
+typedef struct Clients {
+struct Manager *manager;
+int fd;
+dev_t devnum;
+size_t cur;
+size_t max;
+int pass;
+double percent;
+size_t buflen;
+
+LIST_FIELDS(struct Clients, clients);
+} Clients;
Would be better to call this Client.
+typedef struct Manager {
+sd_event *event;
+Clients *clients;
But still 'Client *clients' here.
+if ((fabs(current_percent - m-percent) 0.01) ||
(current_numdevices != m-numdevices)) {
Again, too much parens.
+client = malloc(sizeof(Clients));
new0(Client, 1)
(Unless you initialize all fields, it's better to zero out the structure.)
+if (!client)
+return log_oom();
+client-fd = new_client_fd;
+client-manager = m;
+LIST_PREPEND(clients, m-clients, client);
+r = sd_event_add_io(m-event, NULL, client-fd, EPOLLIN,
progress_handler, client);
+if (r 0) {
+remove_client((m-clients), client);
+return r;
+}
I think you can do this in opposite order, and then the clean-up will
not be necessary.
+m = new0(Manager, 1);
+if (!m)
+return -ENOMEM;
+
+r = sd_event_default(m-event);
+if (r 0)
+return r;
+
+m-clients = NULL;
+m-connection_fd = fd;
+
+m-console = fopen(/dev/console, we);
+if (!m-console)
+return log_error_errno(errno, Can't connect to
/dev/console: %m);
+m-percent = 100;
+m-numdevices = 0;
+m-clear = 0;
Since structure is initialized to zero, there's no need to set stuff to 0 again.
+typedef struct FsckProgress {
+dev_t devnum;
+unsigned long cur;
+unsigned long max;
+int pass;
+} FsckProgress;
I think I asked about that before, but not 100% sure: shouldn't those be size_t?
If they are disk offsets, than long is not enough.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] src/timesync
On Wed, Feb 04, 2015 at 06:10:40PM +0100, Lennart Poettering wrote:
On Wed, 04.02.15 17:09, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
On Wed, Feb 04, 2015 at 08:06:44AM -0800, Lennart Poettering wrote:
src/timesync/timesyncd-manager.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
New commits:
commit 7e3254b3bae19221afefdb87b61ff92c755fd2f4
Author: Lennart Poettering lenn...@poettering.net
Date: Wed Feb 4 17:00:23 2015 +0100
timesyncd: downgrade more log messages from LOG_INFO to LOG_DEBUG
https://bugs.freedesktop.org/show_bug.cgi?id=87505
Let's make timesyncd less chatty.
diff --git a/src/timesync/timesyncd-manager.c
b/src/timesync/timesyncd-manager.c
index d3c62c9..223671c 100644
--- a/src/timesync/timesyncd-manager.c
+++ b/src/timesync/timesyncd-manager.c
@@ -285,7 +285,7 @@ static int manager_clock_watch(sd_event_source
*source, int fd, uint32_t revents
}
/* resync */
-log_info(System time changed. Resyncing.);
+log_debug(System time changed. Resyncing.);
m-poll_resync = true;
return manager_send_request(m);
@@ -740,7 +740,7 @@ static int manager_begin(Manager *m) {
m-poll_interval_usec = NTP_POLL_INTERVAL_MIN_SEC *
USEC_PER_SEC;
server_address_pretty(m-current_server_address, pretty);
-log_info(Using NTP server %s (%s)., strna(pretty),
m-current_server_name-string);
+log_debug(Using NTP server %s (%s)., strna(pretty),
m-current_server_name-string);
sd_notifyf(false, STATUS=Using Time Server %s (%s).,
strna(pretty), m-current_server_name-string);
Hm, but isn't the problem elsewhere? The bug report stated that ipv6
router advertisements cause timesyncd to resync, spamming the time servers.
Indeed. Reopened.
Not sure what the right approach here is though...
Maybe we should just set a flag and ignore network changes until the
normal time for the next sync comes, if we were already sucessfully
synced.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] src/timesync
On Wed, 04.02.15 18:18, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
On Wed, Feb 04, 2015 at 06:10:40PM +0100, Lennart Poettering wrote:
On Wed, 04.02.15 17:09, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
wrote:
On Wed, Feb 04, 2015 at 08:06:44AM -0800, Lennart Poettering wrote:
src/timesync/timesyncd-manager.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
New commits:
commit 7e3254b3bae19221afefdb87b61ff92c755fd2f4
Author: Lennart Poettering lenn...@poettering.net
Date: Wed Feb 4 17:00:23 2015 +0100
timesyncd: downgrade more log messages from LOG_INFO to LOG_DEBUG
https://bugs.freedesktop.org/show_bug.cgi?id=87505
Let's make timesyncd less chatty.
diff --git a/src/timesync/timesyncd-manager.c
b/src/timesync/timesyncd-manager.c
index d3c62c9..223671c 100644
--- a/src/timesync/timesyncd-manager.c
+++ b/src/timesync/timesyncd-manager.c
@@ -285,7 +285,7 @@ static int manager_clock_watch(sd_event_source
*source, int fd, uint32_t revents
}
/* resync */
-log_info(System time changed. Resyncing.);
+log_debug(System time changed. Resyncing.);
m-poll_resync = true;
return manager_send_request(m);
@@ -740,7 +740,7 @@ static int manager_begin(Manager *m) {
m-poll_interval_usec = NTP_POLL_INTERVAL_MIN_SEC *
USEC_PER_SEC;
server_address_pretty(m-current_server_address, pretty);
-log_info(Using NTP server %s (%s)., strna(pretty),
m-current_server_name-string);
+log_debug(Using NTP server %s (%s)., strna(pretty),
m-current_server_name-string);
sd_notifyf(false, STATUS=Using Time Server %s (%s).,
strna(pretty), m-current_server_name-string);
Hm, but isn't the problem elsewhere? The bug report stated that ipv6
router advertisements cause timesyncd to resync, spamming the time
servers.
Indeed. Reopened.
Not sure what the right approach here is though...
Maybe we should just set a flag and ignore network changes until the
normal time for the next sync comes, if we were already sucessfully
synced.
Hmm, what about this:
- If we managed to get a successful sync, don't act on the event, just
wait for the next normal resync
- If we did not manage to get a successful sync, try again
immediately, but not any more often than once per 10s or so...
I think this should make the thing pretty robust and responsive to
network changes when necessary, but not flood the network needlessly?
Makes sense?
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
Hello all,
a little while ago, Jon Severinsson wrote a sysv generator
optimization to not go through all the parsing of init.d scripts and
creation of units if there already is a native unit for that name. As
they are put into generator.late they would be ignored anyway.
This is particularly relevant if you have lots of init.d scripts, like
we have on Debian. Other than that it's not a behaviour change AFAICS.
I cleaned it up a bit and added a test case.
One thing I wonder about is whether native_unit_exists() should
perhaps be moved into src/shared/? It might be useful for other stuff.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From ae066ed5d5b7312eb8debc30970f6e56919fa7c7 Mon Sep 17 00:00:00 2001
From: Jon Severinsson j...@severinsson.net
Date: Wed, 2 Jul 2014 22:00:00 +0200
Subject: [PATCH] sysv-generator: Skip init scripts for existing native
services
There's no need to do all the parsing and creation of service files if we
already have a native systemd unit for the processed SysV init script.
---
src/sysv-generator/sysv-generator.c | 30 +-
test/sysv-generator-test.py | 12
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/src/sysv-generator/sysv-generator.c b/src/sysv-generator/sysv-generator.c
index 673f04d..3052326 100644
--- a/src/sysv-generator/sysv-generator.c
+++ b/src/sysv-generator/sysv-generator.c
@@ -723,6 +723,25 @@ static int fix_order(SysvStub *s, Hashmap *all_services) {
return 0;
}
+static int native_unit_exists(LookupPaths lp, char *name) {
+char **p;
+
+STRV_FOREACH(p, lp.unit_path) {
+struct stat st;
+_cleanup_free_ char *path = NULL;
+
+path = strjoin(*p, /, name, NULL);
+if (!path)
+return -ENOMEM;
+
+if (lstat(path, st) 0)
+continue;
+
+return 1;
+}
+return 0;
+}
+
static int enumerate_sysv(LookupPaths lp, Hashmap *all_services) {
char **path;
@@ -768,6 +787,14 @@ static int enumerate_sysv(LookupPaths lp, Hashmap *all_services) {
if (!fpath)
return log_oom();
+r = native_unit_exists(lp, name);
+if (r 0)
+return log_oom();
+if (r 0) {
+log_debug(Native unit for %s already exists, skipping, *path);
+continue;
+}
+
service = new0(SysvStub, 1);
if (!service)
return log_oom();
@@ -852,7 +879,8 @@ static int set_dependencies_from_rcnd(LookupPaths lp, Hashmap *all_services) {
service = hashmap_get(all_services, name);
if (!service){
-log_warning(Could not find init script for %s, name);
+log_debug(Ignoring %s symlink in %s, not generating %s.,
+ de-d_name, rcnd_table[i].path, name);
continue;
}
diff --git a/test/sysv-generator-test.py b/test/sysv-generator-test.py
index 5098519..89df72a 100644
--- a/test/sysv-generator-test.py
+++ b/test/sysv-generator-test.py
@@ -367,6 +367,18 @@ class SysvGeneratorTest(unittest.TestCase):
self.assert_enabled('foo.bak.service', [])
self.assert_enabled('foo.old.service', [])
+def test_existing_native_unit(self):
+'''existing native unit'''
+
+with open(os.path.join(self.unit_dir, 'foo.service'), 'w') as f:
+f.write('[Unit]\n')
+
+self.add_sysv('foo.sh', {'Provides': 'foo bar'}, enable=True)
+err, results = self.run_generator()
+self.assertEqual(list(results), [])
+# no enablement or alias links
+self.assertEqual(os.listdir(self.out_dir), [])
+
if __name__ == '__main__':
unittest.main(testRunner=unittest.TextTestRunner(stream=sys.stdout, verbosity=2))
--
2.1.4
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] dynamic uid allocation (was: [PATCH] loopback setup in unprivileged containers)
On Tue, Feb 03, 2015 at 06:05:00PM +0100, Lennart Poettering wrote: On Tue, 03.02.15 16:34, Serge Hallyn (serge.hal...@ubuntu.com) wrote: the UID/GID on entire filesystem sub-trees given to containers with userns is a real unpleasant thing to have to deal with. I'd not want Of course you would *not* want to take a stock rootfs where uid == 0 and shift that into the container, as that would give root in the container a chance to write root-owned files on the host to leverage later in a convoluted attack :) Is this really a problem? I mean, the only way how this could be exploitable is if people make the container hierarchy accessible to other users, but that should be easy to prohibit by making the container's parent dir 0700, which we already do for nspawn's container in /var/lib/machines... The only other risk I can see here is that if people use traditional ext4 quota, then the container's disk usage will be added to the host's usage. But that's easy to avoid, by simply never placing container images and the host on the same quota device... Also, in the case of systemd-nspawn we strongly emphasize usage with loopback devices. In that case there's no vulnerability at all, since the device is completely seperate from the host fs, and it will only be mounted in the container, but not in the host... NB, that the container filesystem is visible via /proc/$PID/root, but I agree with you in general. I don't see a reason to avoid the scenario Serge mentioned. Indeed I think it is important that we explicitly support it, because ultimately I think we need to be able to take any arbitrary disk image and safely boot it in either a container or virtual machine. ie we should not have to build custom images just for containers - any such need should be considered a failure of the technology / impl IMHO. We might want to come up with a containers concensus that container rootfs's are always shipped with uid range 0-65535 - 10-165535. That still leaves a chance for container A (mapped to 20-265535) to write valid setuid-root binary for container B (mapped to 30-365535), which isn't possible otherwise. But that's better than doing so for host-root. Well, ultimately I'd recommend an automatism like this for container managers: a) if not otherwise configured, let's give each container their own 16bit of uids. This would mean each 32bit uid could be neatly split into the upper 16bit that would become a container id, plus the lower 16bit for the actual virtual UID. b) we will never set up UID ranges orthogonal from GID ranges. c) when a container image is started, the container manager first checks the UID/GID owner of the root of the root file system. It masks the lower 16bit away, and only looks for the upper 16bit. d) It will then look for an unused container id (which means, an unused range of 64K UIDs), and then shifts the offset it identified following c) to this new container id. With that in place it doesn't really matter which base people use in their containers, the container manager would do the right thing, and shift everything into the right place. Paranoid people could ship their container images shifted to some ID of their choice, and lazy folks could just ship their container images with base 0, but then must make sure they don't give anybody else access to the hierarchy, and don't confuse quota... Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] test-capabilities fail and systemd-timesyncd broken
Okay, Tom fixed this with 057255fbbf2ecb1c46e025b04087fa9340d9880d. 2015-02-03 21:50 GMT+01:00 Daniel Buch boogiewasth...@gmail.com: Hi, This commit 51ddf61540976fc7b09ce5 solved systemd-resolved, but broke systemd-timesyncd. Atleast on my system. dbuch@dbuch-laptop ~ % lscpu | grep -i byte Byte Order:Little Endian dbuch@dbuch-laptop ~ % SYSTEMD_LOGLEVEL=debug sudo /usr/lib/systemd/systemd-timesyncd Failed to enable capabilities bits: Invalid argument I suspect the usage of log2u64() is wrong? Im not able to gork this, but hope this helps :) Kind regards, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] sysctl: consider --prefix while parsing the files
not while applying the parsed sysctl values. Otherwise
info Overwriting earlier assignment of %s in file %s is
visible many times even though the given --prefix doesn't
try to set the overridden value.
---
src/sysctl/sysctl.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/src/sysctl/sysctl.c b/src/sysctl/sysctl.c
index 973e67e..9f9ecc2 100644
--- a/src/sysctl/sysctl.c
+++ b/src/sysctl/sysctl.c
@@ -78,22 +78,6 @@ static int apply_sysctl(const char *property, const char
*value) {
n = stpcpy(p, /proc/sys/);
strcpy(n, property);
-if (!strv_isempty(arg_prefixes)) {
-char **i;
-bool good = false;
-
-STRV_FOREACH(i, arg_prefixes)
-if (path_startswith(p, *i)) {
-good = true;
-break;
-}
-
-if (!good) {
-log_debug(Skipping %s, p);
-return 0;
-}
-}
-
k = write_string_file(p, value);
if (k 0) {
log_full(k == -ENOENT ? LOG_DEBUG : LOG_WARNING,
@@ -173,6 +157,24 @@ static int parse_file(Hashmap *sysctl_options, const char
*path, bool ignore_eno
p = normalize_sysctl(strstrip(p));
value = strstrip(value);
+if (!strv_isempty(arg_prefixes)) {
+char **i, *t;
+bool good = false;
+STRV_FOREACH(i, arg_prefixes) {
+t = *i;
+if (startswith(t, /proc/sys/)) {
+t = t + strlen(/proc/sys/);
+}
+if (path_startswith(p, t)) {
+good = true;
+break;
+}
+}
+if (!good) {
+continue;
+}
+}
+
existing = hashmap_get2(sysctl_options, p, v);
if (existing) {
if (streq(value, existing))
--
2.1.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
2015-02-04 13:42 GMT+01:00 Lennart Poettering lenn...@poettering.net: Hello all, a little while ago, Jon Severinsson wrote a sysv generator optimization to not go through all the parsing of init.d scripts and creation of units if there already is a native unit for that name. As they are put into generator.late they would be ignored anyway. Well, but their enablement status so far is not ignored. i.e. if you drop in a unit file, as well as a sysv script, and the latter is enabled, but the former not, then systemd currently reads that so that the sysv one is overriden by the native one, and the native one is considered enabled. I actually find it confusing, if the enablement state of the sysv init script overrides the native one. What were the reasons to do it this way? The following behaviour is imho more consistent: a/ only a sysv init script available: use sysv init script and its enablement state b/ only a native service file: use native service file and its enablement state c/ both sysv init script and native service file available: use native service file and its enablement state. Take an example, where a single sysv init script foo was split up into multipe systemd unit, like foo.service, foo.socket and bar.service. Isn't it inconsistent, if now, only foo.service was enabled? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
On Wed, 2015-02-04 at 15:06 +0100, Martin Pitt wrote: Lennart Poettering [2015-02-04 13:42 +0100]: Well, but their enablement status so far is not ignored. i.e. if you drop in a unit file, as well as a sysv script, and the latter is enabled, but the former not, then systemd currently reads that so that the sysv one is overriden by the native one, and the native one is considered enabled. With this change you alter that behaviour. Is that really desired? So in that regard it would be an intended behaviour change indeed. But either way this is a corner case for sure. I just wouldn't like to carry this patch forever as it's relatively unimportant. Maybe Jon can chime in about his intentions with this? Isn't this change also relevant to the creation of .wants symlinks, and avoiding generating .wants links from the wrong targets? As in, the case where you override a rcS.d sysvinit service with a multi-user.target systemd unit (or other less common runlevel combinations for distros that don't have any rcS.d level sysv any more). You want to avoid generating a .wants symlink from an early boot target, even if a generated unit file itself would be shadowed by the native unit. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]
On Wed, 2015-02-04 at 19:36 +0100, Lennart Poettering wrote: On Wed, 04.02.15 20:19, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: You're missing an essential point here: there's a distinction between skipping reloads for services which have not not been dispatched, and skipping reloads for services for which startup code is already running (and may be using existing configuration) but which have not reached full running status yet. The former is the correct behavior (but currently handled wrong by systemd!), and never causes races. Only the latter can cause races like described above. These two cases aren't that different. If somebody pushes an additional job into the queue that wants to run before the reload but after the service is up you cannot ot flush out the reload just because the service has not started yet... I cannot parse what you're trying to say here, if it's anything meaningful. Your wants to run before the reload sounds like you're talking about guaranteeing that a reload NOT happen before something else runs, but that would be nonsense - the guarantee would guarantee nothing semantically relevant (if systemd only starts executing the service binary *after* the reload has been queued, it cannot use any pre-reload-order config at any point; there's no guaranteed to use old config guarantee of any form possible!). Whether you change config in your current context, or you do so from a new unit's context is no difference: we cannot move anything that is supposed to happen after that change before it, and we cannot remove it either... If no code from a service is currently running, it's already guaranteed that every request issued to the service in the future will use the new config (no old state exists, and any newly started process will obviously load the new config). Thus the requirements for a reload are already fulfilled; the operation is complete, and there is nothing more to do. Unnecessary waiting only causes deadlocks for no benefit whatsoever. There are some forms of coalescing possible, but we already do all of the ones that are safe... This is not exactly coalescing - it's just immediately returning success if there is no service code running (either in running state or in startup state where a process already exists and could have read the old config before it was changed). Removing the current incorrect blocking and returning success immediately is 100% safe, in the following strictly defined sense: All requests handled by the service after systemctl reload has returned will use a version of config equal or newer than the one that was in effect when the reload call was started. If you still want claim that removing the blocking would not be safe, please try to construct a sequence of operations where such non-blocking behavior would lead to failure (failure defined as: the service processes a request using configuration older than what existed when reload was requested). I'm confident that it is impossible to construct such a counterexample. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]
On Wed, 04.02.15 20:19, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: On Wed, 2015-02-04 at 16:38 +0100, Lennart Poettering wrote: On Wed, 04.02.15 15:25, Martin Pitt (martin.p...@ubuntu.com) wrote: Lennart Poettering [2015-02-04 13:27 +0100]: On Wed, 04.02.15 08:56, Martin Pitt (martin.p...@ubuntu.com) wrote: - Don't enqueue a reload if the service to be reloaded isn't running. E. g. postfix.service inactive/dead in https://bugs.debian.org/635777 or smbd.service start/waiting in https://launchpad.net/bugs/1417010. This would completely avoid the deadlock in most situations already, and doesn't change the semantics for working use cases either, so this should even be applicable for upstream? No, this would open up the door for races. The guarantee we give around blocking operations, is that by the time they return the operation or an equivalent has been executed. More specifically, if you start a service, and it is in starting, and then issue a reload or restart, and it returns you *know* that the configuration that was on disk at the time you issued the reload or restart -- or a newer one -- is in place. If you'd suppress the reload/restart in this case, then you will not get that guarantee, because the configuration ultimately loaded might be the one from the time the daemon was first put into starting mode at. You're missing an essential point here: there's a distinction between skipping reloads for services which have not not been dispatched, and skipping reloads for services for which startup code is already running (and may be using existing configuration) but which have not reached full running status yet. The former is the correct behavior (but currently handled wrong by systemd!), and never causes races. Only the latter can cause races like described above. These two cases aren't that different. If somebody pushes an additional job into the queue that wants to run before the reload but after the service is up you cannot ot flush out the reload just because the service has not started yet... Whether you change config in your current context, or you do so from a new unit's context is no difference: we cannot move anything that is supposed to happen after that change before it, and we cannot remove it either... There are some forms of coalescing possible, but we already do all of the ones that are safe... Fixing the systemd semantics should fix most of the bootup deadlock cases. This is not a sysv workaround or anything like that. The current systemd semantics are wrong and undesirable for new code, regardless of any legacy compatibility issues. Fixing them would give semantics that are more logically correct and work better in practice. No, totally not. THe current semantics give the necessary guarantees that changing a config file from any context you like or queing a file config change from any config you like, and then queuing a reload will take effect, regardless if there's a job for the unit already queued, running or anything else. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
On Wed, 04.02.15 21:26, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: On Wed, 2015-02-04 at 15:06 +0100, Martin Pitt wrote: Lennart Poettering [2015-02-04 13:42 +0100]: Well, but their enablement status so far is not ignored. i.e. if you drop in a unit file, as well as a sysv script, and the latter is enabled, but the former not, then systemd currently reads that so that the sysv one is overriden by the native one, and the native one is considered enabled. With this change you alter that behaviour. Is that really desired? So in that regard it would be an intended behaviour change indeed. But either way this is a corner case for sure. I just wouldn't like to carry this patch forever as it's relatively unimportant. Maybe Jon can chime in about his intentions with this? Isn't this change also relevant to the creation of .wants symlinks, and avoiding generating .wants links from the wrong targets? As in, the case where you override a rcS.d sysvinit service with a multi-user.target systemd unit (or other less common runlevel combinations for distros that don't have any rcS.d level sysv any more). You want to avoid generating a .wants symlink from an early boot target, even if a generated unit file itself would be shadowed by the native unit. systemd does not support sysv scripts for early-boot targets anymore. This has been removed long ago. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Avoid reloading services when shutting down
On Wed, 04.02.15 22:25, Reindl Harald (h.rei...@thelounge.net) wrote: Am 04.02.2015 um 21:57 schrieb Lennart Poettering: OK, let's try this again, with an example: a) you have one service mydaemon.service b) you have a preparation service called mydaemon-convert-config.service that takes config from somewhere, converts it into a suitable format for mydaemon.service's binary Now, you change that config that is located somewhere, issue a restart request for m-c-c.s, issue a reload request for mydaemon.service. Now, something like this should always have the result that your config change is applied to mydaemon.service. Regardless if mydaemon.service's start was queued, is already started or is currently being started. You are suggesting that the reload can suppressed when a start is already enqueued which is true the config change *after* issue restart should not affect the already pending (for whatever reason) restart because this is *unpredictable* bahvior - if i expect that config change to get effective i would issue systemctl reload *before* the restart command We don't make guarantees like that. This is UNIX, we have no transaction file system. We do make guarantees about that if you changed your config and issue a reload, we will not drop that reload. We do not make guarantees whether changing your config concurrently with the daemon confuses the daemon or not. That's between the user and the daemon, we are not involved. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]
On Wed, 04.02.15 22:10, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: On Wed, 2015-02-04 at 19:36 +0100, Lennart Poettering wrote: On Wed, 04.02.15 20:19, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: You're missing an essential point here: there's a distinction between skipping reloads for services which have not not been dispatched, and skipping reloads for services for which startup code is already running (and may be using existing configuration) but which have not reached full running status yet. The former is the correct behavior (but currently handled wrong by systemd!), and never causes races. Only the latter can cause races like described above. These two cases aren't that different. If somebody pushes an additional job into the queue that wants to run before the reload but after the service is up you cannot ot flush out the reload just because the service has not started yet... I cannot parse what you're trying to say here, if it's anything meaningful. No, usually what I am babbling is not meaningful at all... Your wants to run before the reload sounds like you're talking about guaranteeing that a reload NOT happen before something else runs, but that would be nonsense - the guarantee would guarantee nothing semantically relevant (if systemd only starts executing the service binary *after* the reload has been queued, it cannot use any pre-reload-order config at any point; there's no guaranteed to use old config guarantee of any form possible!). OK, let's try this again, with an example: a) you have one service mydaemon.service b) you have a preparation service called mydaemon-convert-config.service that takes config from somewhere, converts it into a suitable format for mydaemon.service's binary Now, you change that config that is located somewhere, issue a restart request for m-c-c.s, issue a reload request for mydaemon.service. Now, something like this should always have the result that your config change is applied to mydaemon.service. Regardless if mydaemon.service's start was queued, is already started or is currently being started. You are suggesting that the reload can suppressed when a start is already enqueued, but that's really not the case, because you first have to run m-c-c.s, before you can reload... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
On Wed, 2015-02-04 at 22:02 +0100, Lennart Poettering wrote: On Wed, 04.02.15 21:26, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: Isn't this change also relevant to the creation of .wants symlinks, and avoiding generating .wants links from the wrong targets? As in, the case where you override a rcS.d sysvinit service with a multi-user.target systemd unit (or other less common runlevel combinations for distros that don't have any rcS.d level sysv any more). You want to avoid generating a .wants symlink from an early boot target, even if a generated unit file itself would be shadowed by the native unit. systemd does not support sysv scripts for early-boot targets anymore. This has been removed long ago. Yes, but Debian patches rcS.d support back in because they still haven't managed to create native units for every package. And as the comment in parenthesis says, the same issue still exists in principle on other distros with other runlevels (though is less common and important than on Debian). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Avoid reloading services when shutting down
Am 04.02.2015 um 21:57 schrieb Lennart Poettering: OK, let's try this again, with an example: a) you have one service mydaemon.service b) you have a preparation service called mydaemon-convert-config.service that takes config from somewhere, converts it into a suitable format for mydaemon.service's binary Now, you change that config that is located somewhere, issue a restart request for m-c-c.s, issue a reload request for mydaemon.service. Now, something like this should always have the result that your config change is applied to mydaemon.service. Regardless if mydaemon.service's start was queued, is already started or is currently being started. You are suggesting that the reload can suppressed when a start is already enqueued which is true the config change *after* issue restart should not affect the already pending (for whatever reason) restart because this is *unpredictable* bahvior - if i expect that config change to get effective i would issue systemctl reload *before* the restart command if you say that is expected behavior than all the warnings about you need to enter systemctl deamon-reload because the unit file changed are pointless and you could just reload automagically all the time signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Avoid reloading services when shutting down
Am 04.02.2015 um 22:31 schrieb Lennart Poettering: On Wed, 04.02.15 22:25, Reindl Harald (h.rei...@thelounge.net) wrote: Am 04.02.2015 um 21:57 schrieb Lennart Poettering: OK, let's try this again, with an example: a) you have one service mydaemon.service b) you have a preparation service called mydaemon-convert-config.service that takes config from somewhere, converts it into a suitable format for mydaemon.service's binary Now, you change that config that is located somewhere, issue a restart request for m-c-c.s, issue a reload request for mydaemon.service. Now, something like this should always have the result that your config change is applied to mydaemon.service. Regardless if mydaemon.service's start was queued, is already started or is currently being started. You are suggesting that the reload can suppressed when a start is already enqueued which is true the config change *after* issue restart should not affect the already pending (for whatever reason) restart because this is *unpredictable* bahvior - if i expect that config change to get effective i would issue systemctl reload *before* the restart command We don't make guarantees like that. This is UNIX, we have no transaction file system. We do make guarantees about that if you changed your config and issue a reload, we will not drop that reload. We do not make guarantees whether changing your config concurrently with the daemon confuses the daemon or not. That's between the user and the daemon, we are not involved i know that all but *you said* above like this should always have the result that your config change is applied to mydaemon.service. Regardless if mydaemon.service's start was queued, is already started or is currently being started that is all i referred to no - my config change shoul *not* get applied when the daemon is currently being started because that is aksing for luck and race conditions and leads in unpredictable behavior if you (systemd) know that the system is about shut down there is no point in reload services at that time signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]
On Wed, 2015-02-04 at 21:57 +0100, Lennart Poettering wrote: OK, let's try this again, with an example: a) you have one service mydaemon.service b) you have a preparation service called mydaemon-convert-config.service that takes config from somewhere, converts it into a suitable format for mydaemon.service's binary Now, you change that config that is located somewhere, issue a restart request for m-c-c.s, issue a reload request for mydaemon.service. Now, something like this should always have the result that your config change is applied to mydaemon.service. Regardless if mydaemon.service's start was queued, is already started or is currently being started. You are suggesting that the reload can suppressed when a start is already enqueued, but that's really not the case, because you first have to run m-c-c.s, before you can reload... I do not see why that would cause any problems with removing the blocking. If you mean literally running systemctl restart mydaemon-convert-config.service; systemctl reload mydaemon.service then this should still work fine - the first restart will block until the operation is complete and new config exists, and then the reload guarantees that no old config is in use. However, I don't see why you'd include the part about creating the new configuration via mydaemon-convert-config.service in this case - the new configuration already exists before any reload functionality is invoked, so why the irrelevant complication of creating that configuration via another service? It seems you are implicitly assuming some kind of parallel execution of the restart and the reload? If you mean something like systemctl restart --no-block mydaemon-convert-config.service; systemctl reload mydaemon.service, I don't see why you'd ever /expect/ this to work with any reload semantics - isn't this clear user error, and will be racy with current systemd code just as much as the proposed fix? There are no ordering constraints here, any more than there would be about starting two services and expecting the first request to be started first. And in any case I'd consider the semantics of reload to be switch to configuration equal or newer than what existed *when the reload was requested*, without any guarantees that changes from operations queued but not finished before calling reload would be taken into account. So unless I completely misunderstood your example, it seems that this does NOT demonstrate any problems with removing the blocking. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
On Wed, 04.02.15 15:06, Martin Pitt (martin.p...@ubuntu.com) wrote: Hey, Lennart Poettering [2015-02-04 13:42 +0100]: Well, but their enablement status so far is not ignored. i.e. if you drop in a unit file, as well as a sysv script, and the latter is enabled, but the former not, then systemd currently reads that so that the sysv one is overriden by the native one, and the native one is considered enabled. With this change you alter that behaviour. Is that really desired? Since it's rather confusing what happens in this case, we made systemctl sync the status to update-rc.d (the chkconfig equivalent in Debian) on enable/disable: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/systemctl-don-t-skip-native-units-when-enabling-disa.patch That of course doesn't change the behaviour with manual rc?.d/ symlinks. But if you have a native unit, I think it's rather unexpected if you disable it with systemctl, enable it in sysv, but still get it started. I'd claim the opposite. Let's say you have foobar.rpm installed in one version that only carried a sysvinit script. Now you upgrade it to a version that has a service file. The fact that it was enabled should not change... Hence, if it is enabled via sysv or via units doesn't matter really right now... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
On Wed, 04.02.15 22:01, Lennart Poettering (lenn...@poettering.net) wrote: On Wed, 04.02.15 15:06, Martin Pitt (martin.p...@ubuntu.com) wrote: Hey, Lennart Poettering [2015-02-04 13:42 +0100]: Well, but their enablement status so far is not ignored. i.e. if you drop in a unit file, as well as a sysv script, and the latter is enabled, but the former not, then systemd currently reads that so that the sysv one is overriden by the native one, and the native one is considered enabled. With this change you alter that behaviour. Is that really desired? Since it's rather confusing what happens in this case, we made systemctl sync the status to update-rc.d (the chkconfig equivalent in Debian) on enable/disable: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/systemctl-don-t-skip-native-units-when-enabling-disa.patch That of course doesn't change the behaviour with manual rc?.d/ symlinks. But if you have a native unit, I think it's rather unexpected if you disable it with systemctl, enable it in sysv, but still get it started. I'd claim the opposite. Let's say you have foobar.rpm installed in one version that only carried a sysvinit script. Now you upgrade it to a version that has a service file. The fact that it was enabled should not change... Hence, if it is enabled via sysv or via units doesn't matter really right now... Anyway, not too convinced that this is really the better option, but not too opposed either. Hence I am OK if something like this goes in. That said, please make sure to share the code from src/share/install.c for this, do not introduce a new search logic for unit files. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
[grr, accidentally dropped the mailing list on my previous reply] 2015-02-04 21:48 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Wed, 04.02.15 21:15, Michael Biebl (mbi...@gmail.com) wrote: 2015-02-04 2:12 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Wed, 04.02.15 02:05, Michael Biebl (mbi...@gmail.com) wrote: [1] http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/debian/rules?id=8341218591c79b4fcfd2542b765b605faff8690b That hack is actually not that ugly... Though incomplete since it will only add refs to runlevel[1-5], but not 0,6... Does it? It adds the wants symlinks to poweroff and reboot as well, and runlevel 0 and 6 are symlinks to those targets: Well, but the goal here is to make sure runlevel0.target and runlevel6.target are at least once referenced. For runlevel[1-5].target this is nicely achieved by pulling in systemd-update-utmp-runlevel.service, since that actually contains After= deps for those 5 runlevel targets... But it doesn't for 0 and 6, which hence never get loaded, thus not fixing the problem for them... But I still think the .wants symlinks from sysv-generator might be the better hack to apply... Do you mean, generating the same set of symlinks as above from within the sysv-generator? I guess I could cobble together a patch for that. No, s-u-u-r.s should not be involved really... Instead, the generator should iterate through runlevel0-6.target, then check where they point and add a .wants symlink from their destination to themselves. When systemd tries to load the .wants/ symlinks it will load these alias, figure out they point back to the respective targets, merge the targets. Finally, it will realize that the wants link is actually on itself, which it suppresses and all is good. Alternatively, we could just create those symlink on make install, if sysv support is enabled. The benefit of a generator is that people can reassign what their runlevels mean simply by overriding the one symlink in /etc/systemd/system for it. We will then derive the other symlink from that, automatically. Since the original patch is from Zbyszek, I'm bringing him into the loop here. Just want to know why he didn't considered pushing this patch upstream. Apparently already two distros patch this downstream, so having a fix upstream would imho make sense. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] slow systemd-networkd DHCP client on wlan0 with systemd v217
On Wed, Feb 4, 2015 at 2:41 PM, Patrik Flykt
patrik.fl...@linux.intel.com wrote:
Hi,
On Tue, 2015-02-03 at 17:27 +0100, Lennart Poettering wrote:
Is the resume event detected somehow in systemd?
The kernel unfortunately provides no API for this right now. However,
if logind is the one suspending the machine, then it sends out a
PrepareForSleep() signal before doing so. systemd-resolved already
hooks into that:
http://cgit.freedesktop.org/systemd/systemd/tree/src/resolve/resolved-bus.c#n684
Tom mentioned he's already looking into adding similar code to
networkd to handle this properly.
Latest upstream works fine for me. Links break at suspend and are
enabled at restore with PrepareForSleep() handled. Both versions of DHCP
properly stop and start at these events.
Yeah, so on all the hardware I had tried so far we got proper
IFF_LOWER_{DOWN,UP} events on suspend/resume. Turns out that is not
always the case, so added the logic to listen for logind for this.
Please let me know if anyone notices problems.
Cheers,
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd not discovering all devices at bootup, and thus no network is configured
Hi again, On Tue, 2015-02-03 at 19:00 +, Keller, Jacob E wrote: Hey, I've recently been using systemd-networkd to great success on a few of my machines here. However I ran into an interesting problem on at least 2 machines so far. I've included the output of journal for systemd-networkd with Environment=SYSTEMD_LOG_LEVEL=debug as was suggested on another post. In addition the only network file I have configured is em0.network which contains the following, $cat /etc/systemd/network/em0.network [Match] Name=em0 [Network] DHCP=Yes The journalctl for systemd-networkd after bootup is, -- Logs begin at Mon 2012-12-31 20:02:09 PST, end at Tue 2015-02-03 10:57:09 PST. -- Feb 03 10:37:44 jekeller-copperpass systemd-networkd[1055]: timestamp of '/etc/systemd/network' changed Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : flags change: +MULTICAST +BROADCAST Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : link 7 added Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : udev initialized link Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : saved original MTU: 1500 Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0 : flags change: +MULTICAST +BROADCAST Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0 : link 8 added Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0 : udev initialized link Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0 : saved original MTU: 1500 Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : MAC address: 7e:5e:7c:31:44:4d Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0 : MAC address: b6:ec:a9:4b:e5:42 Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : getting address failed: Device or resource busy Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : link state is up-to-date Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : unmanaged Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.7 object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: Got message type=signal sender=org.freedesktop.DBus destination=:1.7 object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0 error=n/a Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0 : link state is up-to-date Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0 : unmanaged Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received address for a nonexistent link (1), ignoring Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received address for a nonexistent link (1), ignoring Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0 : flags change: +MULTICAST +BROADCAST Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0 : link 9 added Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0 : udev initialized link Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0 : saved original MTU: 1500 Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0 : link state is up-to-date Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0 : unmanaged Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received address for a nonexistent link (1), ignoring Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received address for a nonexistent link (1), ignoring Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic : flags change: +MULTICAST +BROADCAST Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic : link 10 added Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic : udev initialized link Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic : saved original MTU: 1500 Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic : MAC address: 52:54:00:84:d2:d5 Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic : link state is up-to-date Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic : unmanaged Feb 03 10:37:45 jekeller-copperpass
[systemd-devel] systemd-nspawn create container under unprivileged user
Hello! Does it possible to create container as regular user? Oh what capabilities i need to add to create container not using root? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Restart sequence: systemctl restart rsyslog.service syslog.socket often/sometimes fails
Thank you Lennart for your explanation about the enqueuing. Sounds reasonable. And helps me understand! :-) Here I reply to you a little out of order: On Wed, Feb 4, 2015 at 2:34 PM, Lennart Poettering lenn...@poettering.net wrote: This is something that can be fixed by adding stricter deps between the service and the socket, so that the socket is always required to be started before the service. Something for the respective package maintainers upstream to fix. So have I understood this correctly: That the order matters *is* a bug. Either in systemd (that provides /lib/systemd/system/syslog.socket) or in syslog-ng and rsyslog that provide e.g. /lib/systemd/system/syslog-ng.service ? I'm worried that we manually have to figure out the correct ordering of names to systemctl restart PATTERN and would like to be able to rely on systemctl to figure that out for us. Is that a reasonable long-term expectation? (And the reason order/sequence isn't mentioned in the man page?) Alternatively, only restart the service, don't bother with the socket... That in fact is what we might end up doing as it fixes this instance of the problem short-term. I just want to understand what is going on to determine if we're going to run into headaches long-term. Whats are the precise ordering and requirement deps between those two services? I have no idea what they *should* be, but to show what they *are*, here i show for syslog-ng. Seems to me that syslog-ng is clear about syslog.socket being a dependency: cat /lib/systemd/system/syslog-ng.service [Unit] Description=System Logger Daemon Documentation=man:syslog-ng(8) [Service] Type=notify Sockets=syslog.socket ExecStart=/usr/sbin/syslog-ng -F ExecReload=/bin/kill -HUP $MAINPID StandardOutput=null Restart=on-failure [Install] WantedBy=multi-user.target Alias=syslog.service systemctl list-dependencies -l syslog-ng | cat syslog-ng.service ● ├─syslog.socket ● ├─system.slice ● └─basic.target ● ├─paths.target ● │ └─acpid.path ● ├─slices.target ● │ ├─-.slice ● │ └─system.slice ● ├─sockets.target ● │ ├─acpid.socket ● │ ├─dbus.socket ● │ ├─systemd-initctl.socket ● │ ├─systemd-journald-dev-log.socket ● │ ├─systemd-journald.socket ● │ ├─systemd-shutdownd.socket ● │ ├─systemd-udevd-control.socket ● │ └─systemd-udevd-kernel.socket ● ├─sysinit.target ● │ ├─console-setup.service ● │ ├─debian-fixup.service ● │ ├─dev-hugepages.mount ● │ ├─dev-mqueue.mount ● │ ├─hdparm.service ● │ ├─kbd.service ● │ ├─keyboard-setup.service ● │ ├─kmod-static-nodes.service ● │ ├─networking.service ● │ ├─nfs-common.service ● │ ├─proc-sys-fs-binfmt_misc.automount ● │ ├─rpcbind.service ● │ ├─sys-fs-fuse-connections.mount ● │ ├─sys-kernel-config.mount ● │ ├─sys-kernel-debug.mount ● │ ├─systemd-ask-password-console.path ● │ ├─systemd-binfmt.service ● │ ├─systemd-journal-flush.service ● │ ├─systemd-journald.service ● │ ├─systemd-modules-load.service ● │ ├─systemd-random-seed.service ● │ ├─systemd-sysctl.service ● │ ├─systemd-tmpfiles-setup-dev.service ● │ ├─systemd-tmpfiles-setup.service ● │ ├─systemd-udev-trigger.service ● │ ├─systemd-udevd.service ● │ ├─systemd-update-utmp.service ● │ ├─udev-finish.service ● │ ├─vmware-tools.service ● │ ├─cryptsetup.target ● │ ├─local-fs.target ● │ │ ├─-.mount ● │ │ ├─jail-dev.mount ● │ │ ├─jail-proc.mount ● │ │ ├─jail-tftp-cliusers.mount ● │ │ ├─systemd-fsck-root.service ● │ │ └─systemd-remount-fs.service ● │ └─swap.target ● │ ├─dev-disk-by\x2duuid-37ac7cd8\x2d4a9c\x2d4118\x2d8192\x2d7ecaf6229d75.swap ● │ └─dev-disk-by\x2duuid-37ac7cd8\x2d4a9c\x2d4118\x2d8192\x2d7ecaf6229d75.swap ● └─timers.target ● └─systemd-tmpfiles-clean.timer Thanks, Peter -- Peter Valdemar Mørch http://www.morch.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv2] sysctl: consider --prefix while parsing the files
On Wed, Feb 04, 2015 at 03:50:01PM +0100, Umut Tezduyar Lindskog wrote:
not while applying the parsed sysctl values. Otherwise
info Overwriting earlier assignment of %s in file %s is
visible many times even though the given --prefix doesn't
try to set the overridden value.
---
src/sysctl/sysctl.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/src/sysctl/sysctl.c b/src/sysctl/sysctl.c
index 973e67e..b22aff5 100644
--- a/src/sysctl/sysctl.c
+++ b/src/sysctl/sysctl.c
@@ -78,22 +78,6 @@ static int apply_sysctl(const char *property, const char
*value) {
n = stpcpy(p, /proc/sys/);
strcpy(n, property);
-if (!strv_isempty(arg_prefixes)) {
-char **i;
-bool good = false;
-
-STRV_FOREACH(i, arg_prefixes)
-if (path_startswith(p, *i)) {
-good = true;
-break;
-}
-
-if (!good) {
-log_debug(Skipping %s, p);
-return 0;
-}
-}
-
k = write_string_file(p, value);
if (k 0) {
log_full(k == -ENOENT ? LOG_DEBUG : LOG_WARNING,
@@ -173,6 +157,22 @@ static int parse_file(Hashmap *sysctl_options, const
char *path, bool ignore_eno
p = normalize_sysctl(strstrip(p));
value = strstrip(value);
+if (!strv_isempty(arg_prefixes)) {
+char **i, *t;
+bool good = false;
+STRV_FOREACH(i, arg_prefixes) {
+t = path_startswith(*i, /proc/sys/);
+if (t == NULL)
+t = *i;
+if (path_startswith(p, t)) {
+good = true;
+break;
+}
+}
+if (!good)
+continue;
+}
While at it, wouldn't it be better to use a goto and do away with the
good variable. This will give a diff of -7/+3, a win also for readability imho.
Zbyszek
+
existing = hashmap_get2(sysctl_options, p, v);
if (existing) {
if (streq(value, existing))
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] fsckd daemon for inter-fsckd communication
From 74291bace60f64efb96287f8170df4c38058cc46 Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Wed, 4 Feb 2015 16:42:47 +0100
Subject: [PATCH 2/2] fsckd daemon for inter-fsckd communication
Add systemd-fsckd multiplexer which accepts multiple systemd-fsck
instances to connect to it and sends progress report. systemd-fsckd then
computes and writes to /dev/console the number of devices currently being
checked and the minimum fsck progress. This will be used for interactive
progress report and cancelling in plymouth.
systemd-fsckd stops on idle when no systemd-fsck is connected.
Make the necessary changes to systemd-fsck to connect to the systemd-fsckd
socket.
---
.gitignore | 1 +
Makefile.am| 13 ++
src/fsck/fsck.c| 88 +
src/fsckd/Makefile | 1 +
src/fsckd/fsckd.c | 370 +
src/fsckd/fsckd.h | 34 +
6 files changed, 453 insertions(+), 54 deletions(-)
create mode 12 src/fsckd/Makefile
create mode 100644 src/fsckd/fsckd.c
create mode 100644 src/fsckd/fsckd.h
diff --git a/.gitignore b/.gitignore
index ab6d9d1..9400e75 100644
--- a/.gitignore
+++ b/.gitignore
@@ -74,6 +74,7 @@
/systemd-evcat
/systemd-firstboot
/systemd-fsck
+/systemd-fsckd
/systemd-fstab-generator
/systemd-getty-generator
/systemd-gnome-ask-password-agent
diff --git a/Makefile.am b/Makefile.am
index c463f23..e0e8bc6 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -389,6 +389,7 @@ rootlibexec_PROGRAMS = \
systemd-remount-fs \
systemd-reply-password \
systemd-fsck \
+ systemd-fsckd \
systemd-machine-id-commit \
systemd-ac-power \
systemd-sysctl \
@@ -2355,6 +2356,18 @@ systemd_fsck_LDADD = \
libsystemd-shared.la
# --
+systemd_fsckd_SOURCES = \
+ src/fsckd/fsckd.c \
+ $(NULL)
+
+systemd_fsckd_LDADD = \
+ libsystemd-internal.la \
+ libsystemd-label.la \
+ libsystemd-shared.la \
+ libudev-internal.la \
+ $(NULL)
+
+# --
systemd_machine_id_commit_SOURCES = \
src/machine-id-commit/machine-id-commit.c \
src/core/machine-id-setup.c \
diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index 20b7940..9d9739b 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -27,6 +27,7 @@
#include unistd.h
#include fcntl.h
#include sys/file.h
+#include sys/stat.h
#include sd-bus.h
#include libudev.h
@@ -39,6 +40,8 @@
#include fileio.h
#include udev-util.h
#include path-util.h
+#include socket-util.h
+#include fsckd/fsckd.h
static bool arg_skip = false;
static bool arg_force = false;
@@ -132,58 +135,42 @@ static void test_files(void) {
arg_show_progress = true;
}
-static double percent(int pass, unsigned long cur, unsigned long max) {
-/* Values stolen from e2fsck */
-
-static const int pass_table[] = {
-0, 70, 90, 92, 95, 100
+static int process_progress(int fd, dev_t device_num) {
+_cleanup_fclose_ FILE *f = NULL;
+usec_t last = 0;
+_cleanup_close_ int fsckd_fd = -1;
+static const union sockaddr_union sa = {
+.un.sun_family = AF_UNIX,
+.un.sun_path = FSCKD_SOCKET_PATH,
};
-if (pass = 0)
-return 0.0;
-
-if ((unsigned) pass = ELEMENTSOF(pass_table) || max == 0)
-return 100.0;
-
-return (double) pass_table[pass-1] +
-((double) pass_table[pass] - (double) pass_table[pass-1]) *
-(double) cur / (double) max;
-}
-
-static int process_progress(int fd) {
-_cleanup_fclose_ FILE *console = NULL, *f = NULL;
-usec_t last = 0;
-bool locked = false;
-int clear = 0;
+fsckd_fd = socket(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0);
+if (fsckd_fd 0) {
+log_warning_errno(errno, Cannot open fsckd socket, we won't report fsck progress: %m);
+return -errno;
+}
+if (connect(fsckd_fd, sa.sa, offsetof(struct sockaddr_un, sun_path) + strlen(sa.un.sun_path)) 0) {
+log_warning_errno(errno, Cannot connect to fsckd socket, we won't report fsck progress: %m);
+return -errno;
+}
f = fdopen(fd, r);
if (!f) {
-safe_close(fd);
+log_warning_errno(errno, Cannot connect to fsck, we won't report fsck progress: %m);
return -errno;
}
-console = fopen(/dev/console, we);
-if (!console)
-return -ENOMEM;
-
while (!feof(f)) {
-int pass, m;
-unsigned long cur, max;
-_cleanup_free_ char *device = NULL;
-double p;
+int pass;
+size_t cur, max;
+ssize_t n;
usec_t t;
+_cleanup_free_ char *device =
[systemd-devel] [PATCH 1/2] Add sd_event_loop_timeout to sd_event
Hey,
I rewrote a version of this patch including the feedback on the list. As
per IRC discussion, (and after giving up the busy loop for a rewrite
with epool), I did rebase it again on sd_event.
I'm only proposing there up for review the 2 first patches (without
plymouth communication, cancel support, i18n, man pages and the service
and socket) so that I don't have to rebase all other 10 patches on a
moving ground.
I'm opened to any feedback and fixes to do :)
Cheers,
Didier
From 52d3c92280ec6198a0566bd3a077c0fbb6990782 Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Wed, 4 Feb 2015 16:40:44 +0100
Subject: [PATCH 1/2] Add sd_event_loop_timeout to sd_event
sd_event_loop_timeout adds a timeout parameter to sd_event_loop() to timeout
the whole event loop after some time of inactivity.
---
src/libsystemd/sd-event/sd-event.c | 10 +++---
src/systemd/sd-event.h | 1 +
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/libsystemd/sd-event/sd-event.c b/src/libsystemd/sd-event/sd-event.c
index f9fa54d..8dd3e16 100644
--- a/src/libsystemd/sd-event/sd-event.c
+++ b/src/libsystemd/sd-event/sd-event.c
@@ -2496,7 +2496,7 @@ _public_ int sd_event_run(sd_event *e, uint64_t timeout) {
return r;
}
-_public_ int sd_event_loop(sd_event *e) {
+_public_ int sd_event_loop_timeout(sd_event *e, uint64_t timeout) {
int r;
assert_return(e, -EINVAL);
@@ -2506,8 +2506,8 @@ _public_ int sd_event_loop(sd_event *e) {
sd_event_ref(e);
while (e-state != SD_EVENT_FINISHED) {
-r = sd_event_run(e, (uint64_t) -1);
-if (r 0)
+r = sd_event_run(e, timeout);
+if (r 0 || (r == 0 timeout != (uint64_t) -1))
goto finish;
}
@@ -2518,6 +2518,10 @@ finish:
return r;
}
+_public_ int sd_event_loop(sd_event *e) {
+return sd_event_loop_timeout(e, (uint64_t) -1);
+}
+
_public_ int sd_event_get_fd(sd_event *e) {
assert_return(e, -EINVAL);
diff --git a/src/systemd/sd-event.h b/src/systemd/sd-event.h
index 25a10f9..53e2382 100644
--- a/src/systemd/sd-event.h
+++ b/src/systemd/sd-event.h
@@ -90,6 +90,7 @@ int sd_event_prepare(sd_event *e);
int sd_event_wait(sd_event *e, uint64_t timeout);
int sd_event_dispatch(sd_event *e);
int sd_event_run(sd_event *e, uint64_t timeout);
+int sd_event_loop_timeout(sd_event *e, uint64_t timeout);
int sd_event_loop(sd_event *e);
int sd_event_exit(sd_event *e, int code);
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv2 3/4] systemctl: cat, edit: further polish error messages
---
src/systemctl/systemctl.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 567b467..384ae02 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4578,7 +4578,7 @@ static int init_home_and_lookup_paths(char **user_home,
char **user_runtime, Loo
r = lookup_paths_init_from_scope(lp, arg_scope, arg_root);
if (r 0)
-return log_error_errno(r, Failed to lookup unit lookup paths:
%m);
+return log_error_errno(r, Failed to query unit lookup paths:
%m);
return 0;
}
@@ -5725,11 +5725,11 @@ static int create_edit_temp_file(const char *new_path,
const char *original_path
r = tempfn_random(new_path, t);
if (r 0)
-return log_error_errno(r, Failed to determine temporary
filename for %s: %m, new_path);
+return log_error_errno(r, Failed to determine temporary
filename for \%s\: %m, new_path);
r = mkdir_parents(new_path, 0755);
if (r 0) {
-log_error_errno(r, Failed to create directories for %s: %m,
new_path);
+log_error_errno(r, Failed to create directories for \%s\:
%m, new_path);
free(t);
return r;
}
@@ -5738,12 +5738,12 @@ static int create_edit_temp_file(const char *new_path,
const char *original_path
if (r == -ENOENT) {
r = touch(t);
if (r 0) {
-log_error_errno(r, Failed to create temporary file
%s: %m, t);
+log_error_errno(r, Failed to create temporary file
\%s\: %m, t);
free(t);
return r;
}
} else if (r 0) {
-log_error_errno(r, Failed to copy %s to %s: %m,
original_path, t);
+log_error_errno(r, Failed to copy \%s\ to \%s\: %m,
original_path, t);
free(t);
return r;
}
@@ -5851,7 +5851,7 @@ static int unit_file_create_copy(const char *unit_name,
if (!path_equal(fragment_path, tmp_new_path) access(tmp_new_path,
F_OK) == 0) {
char response;
-r = ask_char(response, yn, %s already exists, are you sure
to overwrite it with %s? [(y)es, (n)o] , tmp_new_path, fragment_path);
+r = ask_char(response, yn, \%s\ already exists.
Overwrite with \%s\? [(y)es, (n)o] , tmp_new_path, fragment_path);
if (r 0) {
free(tmp_new_path);
return r;
@@ -5865,7 +5865,7 @@ static int unit_file_create_copy(const char *unit_name,
r = create_edit_temp_file(tmp_new_path, fragment_path, tmp_tmp_path);
if (r 0) {
-log_error_errno(r, Failed to create temporary file for %s:
%m, tmp_new_path);
+log_error_errno(r, Failed to create temporary file for
\%s\: %m, tmp_new_path);
free(tmp_new_path);
return r;
}
@@ -6001,7 +6001,7 @@ static int edit(sd_bus *bus, char **args) {
assert(args);
if (!on_tty()) {
-log_error(Cannot edit units if we are not on a tty);
+log_error(Cannot edit units if not on a tty);
return -EINVAL;
}
@@ -6030,12 +6030,12 @@ static int edit(sd_bus *bus, char **args) {
* It's useful if the user wants to cancel its modification
*/
if (null_or_empty_path(*tmp)) {
-log_warning(Edition of %s canceled: temporary file
empty, *original);
+log_warning(Editing \%s\ canceled: temporary file
is empty, *original);
continue;
}
r = rename(*tmp, *original);
if (r 0) {
-r = log_error_errno(errno, Failed to rename %s to %s:
%m, *tmp, *original);
+r = log_error_errno(errno, Failed to rename \%s\ to
\%s\: %m, *tmp, *original);
goto end;
}
}
--
2.2.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Wed, Feb 04, 2015 at 09:53:20PM +0100, Michael Biebl wrote: [grr, accidentally dropped the mailing list on my previous reply] 2015-02-04 21:48 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Wed, 04.02.15 21:15, Michael Biebl (mbi...@gmail.com) wrote: 2015-02-04 2:12 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Wed, 04.02.15 02:05, Michael Biebl (mbi...@gmail.com) wrote: [1] http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/debian/rules?id=8341218591c79b4fcfd2542b765b605faff8690b That hack is actually not that ugly... Though incomplete since it will only add refs to runlevel[1-5], but not 0,6... Does it? It adds the wants symlinks to poweroff and reboot as well, and runlevel 0 and 6 are symlinks to those targets: Well, but the goal here is to make sure runlevel0.target and runlevel6.target are at least once referenced. For runlevel[1-5].target this is nicely achieved by pulling in systemd-update-utmp-runlevel.service, since that actually contains After= deps for those 5 runlevel targets... But it doesn't for 0 and 6, which hence never get loaded, thus not fixing the problem for them... But I still think the .wants symlinks from sysv-generator might be the better hack to apply... Do you mean, generating the same set of symlinks as above from within the sysv-generator? I guess I could cobble together a patch for that. No, s-u-u-r.s should not be involved really... Instead, the generator should iterate through runlevel0-6.target, then check where they point and add a .wants symlink from their destination to themselves. When systemd tries to load the .wants/ symlinks it will load these alias, figure out they point back to the respective targets, merge the targets. Finally, it will realize that the wants link is actually on itself, which it suppresses and all is good. Alternatively, we could just create those symlink on make install, if sysv support is enabled. The benefit of a generator is that people can reassign what their runlevels mean simply by overriding the one symlink in /etc/systemd/system for it. We will then derive the other symlink from that, automatically. Since the original patch is from Zbyszek, I'm bringing him into the loop here. Just want to know why he didn't considered pushing this patch upstream. Apparently already two distros patch this downstream, so having a fix upstream would imho make sense. Because it was just a hack :) Maybe Lennart's idea with the sysv generator is a better thing. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
On 02/04/2015 09:20 PM, Lennart Poettering wrote: On Wed, 04.02.15 22:01, Lennart Poettering (lenn...@poettering.net) wrote: On Wed, 04.02.15 15:06, Martin Pitt (martin.p...@ubuntu.com) wrote: Hey, Lennart Poettering [2015-02-04 13:42 +0100]: Well, but their enablement status so far is not ignored. i.e. if you drop in a unit file, as well as a sysv script, and the latter is enabled, but the former not, then systemd currently reads that so that the sysv one is overriden by the native one, and the native one is considered enabled. With this change you alter that behaviour. Is that really desired? Since it's rather confusing what happens in this case, we made systemctl sync the status to update-rc.d (the chkconfig equivalent in Debian) on enable/disable: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/systemctl-don-t-skip-native-units-when-enabling-disa.patch That of course doesn't change the behaviour with manual rc?.d/ symlinks. But if you have a native unit, I think it's rather unexpected if you disable it with systemctl, enable it in sysv, but still get it started. I'd claim the opposite. Let's say you have foobar.rpm installed in one version that only carried a sysvinit script. Now you upgrade it to a version that has a service file. The fact that it was enabled should not change... Hence, if it is enabled via sysv or via units doesn't matter really right now... Anyway, not too convinced that this is really the better option, but not too opposed either. Hence I am OK if something like this goes in. Could not a downstream use a component based preset file hack to overcome this? + this is extremely limited to Debian and Debian based distribution these days and since you don't seem to recall what happened in Fedora during the transaction period where users had to manually enable services ( again ) after the change from the legacy script to unit in components during upgrades ( that chkconfig hack FPC came up with, approved, implemented and had everybody follow to handle upgrades did not work, like many other decision FPC has come up with and made in their infinite collective wisdom ). I expect Debian to do the same sane thing as everyone else did back in the day and strike out that components will be allowed to migrate to units after beta ( or no later then just before the final release ), so end users running the latest stable version of Debian that started with an installed sys script wont suddenly find themselves in midst of it's release cycle switching to units. Those doing release upgrades can as always expect breakage and or manual intervention of some sort so manually enable stuff again is not to overcoming and is not a usecase to consider. Then next thing the Debian community will realize is that once maintainers have made the switch to use units they will have to stick the legacy sysv initscript in a separated sub component which will depend on a virtual provide for all the other init systems ( that is if the maintainers want to support those et all ). The Debian maintainers and or it's leader can already cut corners in exhausting decision making and policy handling and just look at how all the other distribution ( fedora,opensuse,mageia etc ) handled this and have handle this and follow it ( as oppose to re-invent the wheel ) and keep all workarounds and hacks to support that transformation and multiple init system downstream ( like everyone else had to do ). JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv2 4/4] systemctl: unit_find_paths(): unify error handling in two code pathes
---
src/systemctl/systemctl.c | 63 ++-
1 file changed, 35 insertions(+), 28 deletions(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 384ae02..2d70ff1 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -2293,6 +2293,9 @@ static int unit_find_paths(sd_bus *bus,
LookupPaths *lp,
char **fragment_path,
char ***dropin_paths) {
+
+_cleanup_free_ char *path = NULL;
+_cleanup_strv_free_ char **dropins = NULL;
int r;
/**
@@ -2311,8 +2314,6 @@ static int unit_find_paths(sd_bus *bus,
_cleanup_bus_error_free_ sd_bus_error error =
SD_BUS_ERROR_NULL;
_cleanup_bus_message_unref_ sd_bus_message *unit_load_error =
NULL;
_cleanup_free_ char *unit = NULL;
-_cleanup_free_ char *path = NULL;
-_cleanup_strv_free_ char **dropins = NULL;
_cleanup_strv_free_ char **load_error = NULL;
char *unit_load_error_name, *unit_load_error_message;
@@ -2359,28 +2360,17 @@ static int unit_find_paths(sd_bus *bus,
if (r 0)
return log_error_errno(r, Failed to get FragmentPath:
%s, bus_error_message(error, r));
-r = sd_bus_get_property_strv(
-bus,
-org.freedesktop.systemd1,
-unit,
-org.freedesktop.systemd1.Unit,
-DropInPaths,
-error,
-dropins);
-if (r 0)
-return log_error_errno(r, Failed to get DropInPaths:
%s, bus_error_message(error, r));
-
-r = 0;
-if (!isempty(path)) {
-*fragment_path = path;
-path = NULL;
-r = 1;
-}
-
-if (dropin_paths !strv_isempty(dropins)) {
-*dropin_paths = dropins;
-dropins = NULL;
-r = 1;
+if (dropin_paths) {
+r = sd_bus_get_property_strv(
+bus,
+org.freedesktop.systemd1,
+unit,
+org.freedesktop.systemd1.Unit,
+DropInPaths,
+error,
+dropins);
+if (r 0)
+return log_error_errno(r, Failed to get
DropInPaths: %s, bus_error_message(error, r));
}
} else {
_cleanup_set_free_ Set *names;
@@ -2393,7 +2383,7 @@ static int unit_find_paths(sd_bus *bus,
if (r 0)
return r;
-r = unit_file_find_path(lp, unit_name, fragment_path);
+r = unit_file_find_path(lp, unit_name, path);
if (r 0)
return r;
@@ -2405,14 +2395,31 @@ static int unit_find_paths(sd_bus *bus,
return log_oom();
if (!streq(template, unit_name)) {
-r = unit_file_find_path(lp, template,
fragment_path);
+r = unit_file_find_path(lp, template, path);
if (r 0)
return r;
}
}
-if (dropin_paths)
-r = unit_file_find_dropin_paths(lp-unit_path, NULL,
names, dropin_paths);
+if (dropin_paths) {
+r = unit_file_find_dropin_paths(lp-unit_path, NULL,
names, dropins);
+if (r 0)
+return r;
+}
+}
+
+r = 0;
+
+if (!isempty(path)) {
+*fragment_path = path;
+path = NULL;
+r = 1;
+}
+
+if (dropin_paths !strv_isempty(dropins)) {
+*dropin_paths = dropins;
+dropins = NULL;
+r = 1;
}
if (r == 0)
--
2.2.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv2 2/4] systemctl: cat: fix error handling
- correctly check for local vs. remote transport
- return after receiving error from expand_names()
---
src/systemctl/systemctl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 083b618..567b467 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4594,8 +4594,8 @@ static int cat(sd_bus *bus, char **args) {
assert(args);
-if (arg_host) {
-log_error(Option --host cannot be used with 'cat');
+if (arg_transport != BUS_TRANSPORT_LOCAL) {
+log_error(Cannot remotely cat units);
return -EINVAL;
}
@@ -4605,7 +4605,7 @@ static int cat(sd_bus *bus, char **args) {
r = expand_names(bus, args + 1, NULL, names);
if (r 0)
-log_error_errno(r, Failed to expand names: %m);
+return log_error_errno(r, Failed to expand names: %m);
avoid_bus_cache = !bus || avoid_bus();
--
2.2.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv2 1/4] systemctl: cat, edit: improve unit load error reporting
- report actual load error for units which could not be loaded
- make unit_find_paths() report all kinds of errors it encounters
(for consistency)
- consistently handle not-found errors in cat() and edit()
---
src/systemctl/systemctl.c | 54 +++
1 file changed, 40 insertions(+), 14 deletions(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 462f7fd..083b618 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -2309,9 +2309,12 @@ static int unit_find_paths(sd_bus *bus,
if (!avoid_bus_cache !unit_name_is_template(unit_name)) {
_cleanup_bus_error_free_ sd_bus_error error =
SD_BUS_ERROR_NULL;
+_cleanup_bus_message_unref_ sd_bus_message *unit_load_error =
NULL;
_cleanup_free_ char *unit = NULL;
_cleanup_free_ char *path = NULL;
_cleanup_strv_free_ char **dropins = NULL;
+_cleanup_strv_free_ char **load_error = NULL;
+char *unit_load_error_name, *unit_load_error_message;
unit = unit_dbus_path_from_name(unit_name);
if (!unit)
@@ -2320,6 +2323,31 @@ static int unit_find_paths(sd_bus *bus,
if (need_daemon_reload(bus, unit_name) 0)
warn_unit_file_changed(unit_name);
+r = sd_bus_get_property(
+bus,
+org.freedesktop.systemd1,
+unit,
+org.freedesktop.systemd1.Unit,
+LoadError,
+error,
+unit_load_error,
+(ss));
+if (r 0)
+return log_error_errno(r, Failed to get LoadError:
%s, bus_error_message(error, r));
+
+r = sd_bus_message_read(
+unit_load_error,
+(ss),
+unit_load_error_name,
+unit_load_error_message);
+if (r 0)
+return bus_log_parse_error(r);
+
+if (!isempty(unit_load_error_name)) {
+log_error(Unit %s is not loaded: %s, unit_name,
unit_load_error_message);
+return 0;
+}
+
r = sd_bus_get_property_string(
bus,
org.freedesktop.systemd1,
@@ -2387,6 +2415,9 @@ static int unit_find_paths(sd_bus *bus,
r = unit_file_find_dropin_paths(lp-unit_path, NULL,
names, dropin_paths);
}
+if (r == 0)
+log_error(No files found for %s., unit_name);
+
return r;
}
@@ -4588,10 +4619,8 @@ static int cat(sd_bus *bus, char **args) {
r = unit_find_paths(bus, *name, avoid_bus_cache, lp,
fragment_path, dropin_paths);
if (r 0)
return r;
-else if (r == 0) {
-log_warning(Unit %s does not have any files on disk,
*name);
-continue;
-}
+else if (r == 0)
+return -ENOENT;
if (first)
first = false;
@@ -5940,9 +5969,13 @@ static int find_paths_to_edit(sd_bus *bus, char **names,
char ***paths) {
r = unit_find_paths(bus, *name, avoid_bus_cache, lp, path,
NULL);
if (r 0)
return r;
-else if (r == 0 || !path)
+else if (r == 0)
+return -ENOENT;
+else if (!path) {
// FIXME: support units with path==NULL (no
FragmentPath)
-return log_error_errno(ENOENT, Unit %s not found,
cannot edit., *name);
+log_error(No fragment exists for %s., *name);
+return -ENOENT;
+}
if (arg_full)
r = unit_file_create_copy(*name, path, user_home,
user_runtime, new_path, tmp_path);
@@ -5981,19 +6014,12 @@ static int edit(sd_bus *bus, char **args) {
if (r 0)
return log_error_errno(r, Failed to expand names: %m);
-if (!names) {
-log_error(No unit name found by expanding names);
-return -ENOENT;
-}
-
r = find_paths_to_edit(bus, names, paths);
if (r 0)
return r;
-if (strv_isempty(paths)) {
-log_error(Cannot find any units to edit);
+if (strv_isempty(paths))
return -ENOENT;
-}
r = run_editor(paths);
if (r 0)
--
2.2.2
___
Re: [systemd-devel] bug 88401 / daemon-reload causes Type=oneshot services to be re-started / path_coldplug() is non-deserialization-aware
On 2015-01-28 at 22:29 +0300, Ivan Shapovalov wrote:
On 2015-01-28 at 20:15 +0100, Lennart Poettering wrote:
On Sun, 18.01.15 04:21, Ivan Shapovalov (intelfx...@gmail.com) wrote:
Hi folks,
I'm trying to fix this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88401
The initial problem (as reported) looks following: performing a reload
(maybe implicitly) re-starts alsa-restore.service if it is enabled.
With a bit of debugging I've apparently found a root cause. Explanation
following.
Suppose we have CUPS installed and org.cups.cupsd.{path,service} are
started.
We enter manager_reload(), units are serialized, reset, re-read,
deserialized and then cold-plugged. (Note that e. g. unit_notify() has
special protection to avoid spawning jobs when a reload is in
progress.)
So, if org.cups.cupsd.path is started, *it is almost first to be
cold-plugged*. The call chain is:
unit_coldplug()
path_coldplug()
path_enter_waiting() // recheck == true
path_check_good() // returns true
path_enter_running()
manager_add_job() // at this point we're fucked up
So, a job is enqueued for org.cups.cupsd.service. This is already wrong,
because a reload should never enqueue any jobs (IIUC). So, the job is
enqueued... remember that almost all units are inactive by now. Thus we
end up re-starting half a system (the whole basic.target) as
dependencies.
Questions:
- is my analysis correct?
- if yes, then how to fix this? Maybe add a similar
if (UNIT(p)-manager-n_reloading = 0) check to
path_enter_running() to avoid calling manager_add_job() during
reloading?
Hmm, how does this relate to the ALSA case? I mean, the alsa units
don't use .path units, do they?
The .path unit from CUPS is triggered and starts its .service unit
*while the service unit's state has not yet been coldplugged*.
Actually, almost nothing is coldplugged at that point. Thus the
basic.target is effectively re-started with all its dependencies,
ignoring all existing state (because it is not yet coldplugged). This
is the actual bug, and it is the root cause of the reported bug.
Reported bug, on the other hand, happens due to
1) the above-described bug (not related to alsa) takes place;
2) alsa-restore.service is Type=oneshot, RemainAfterExit=false and
WantedBy=basic.target.
Hope it makes things clearer...
Ping? Lennart, do you understand what's going on, or should I try to
describe things more carefully?
// I would like to get this fixed before v219 ;)
Thanks.
--
Ivan Shapovalov / intelfx /
signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Container, private network and socket activation
That indicates that the systemd or apache inside the container do not correctly make use of the the socket passed into them. You need to make sure that inside the container you have pretty much the same .socket unit running as on the host. The ListStream lines must be identical, so that systemd inside the container recognizes the sockets passed in from the host as the ones to use for apache. The only difference for the socket units is that on the host they should activate the container, in the container they should activate apache. ... Well, because the socket wasn't passed on right the connection on it will still be queued after the container exits again. systemd will thus immediately spawn the container again. Basically, if you fix your issue #1, your issue #3 will be magically fixed too. Now I understand the mechanizm, at least I think so. Unfortunately I have apache 2.4.x . I tried to apply the patches Christian Seiler mentioned, but I was unable to build the package. I think I have to wait a little bit longer in order to make it work. Anyway, I tried to reproduce the ssh example (it can be found here: http://0pointer.net/blog/projects/socket-activated-containers.html) just for testing purposes, and I dont't experience the rebooting issue anymore, but there's another thing: morfik:~$ ssh -p 23 192.168.10.10 ^C morfik:~$ ssh -p 23 192.168.10.10 ssh: connect to host 192.168.10.10 port 23: Connection refused The container started when I had tried to connect for the first time, but I couldn't connect to this port after that, and I have no idea why. I tried to figure out what went wrong, but I failed. # machinectl status debian-tree -l --no-pager debian-tree Since: Thu 2015-02-05 00:21:41 CET; 1min 16s ago Leader: 103953 (systemd) Service: nspawn; class container Root: /media/Kabi/debian-tree Address: 192.168.10.10 fe80::1474:8dff:fe79:6b44 OS: Debian GNU/Linux 8 (jessie) Unit: machine-debian\x2dtree.scope ├─103953 /lib/systemd/systemd 3 └─system.slice ├─dbus.service │ └─104069 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation ├─cron.service │ └─104043 /usr/sbin/cron -f ├─apache2.service │ ├─104481 /usr/sbin/apache2 -k start │ ├─104485 /usr/sbin/apache2 -k start │ ├─104511 /usr/sbin/apache2 -k start │ ├─104512 /usr/sbin/apache2 -k start │ ├─104513 /usr/sbin/apache2 -k start │ ├─104515 /usr/sbin/apache2 -k start │ └─104516 /usr/sbin/apache2 -k start ├─system-sshd.slice │ └─sshd@0-192.168.10.10:23-192.168.10.10:51767.service │ ├─104041 sshd: [accepted] │ └─104042 sshd: [net] ├─systemd-journald.service │ └─103975 /lib/systemd/systemd-journald ├─systemd-logind.service │ └─104046 /lib/systemd/systemd-logind ├─mysql.service │ ├─104090 /bin/sh /usr/bin/mysqld_safe │ └─104453 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --log-error=/var/log/mysql/error.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port= ├─console-getty.service │ └─104208 /sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt102 └─rsyslog.service └─104088 /usr/sbin/rsyslogd -n Then I logged into the container: root:~# machinectl login debian-tree ... root@www:/home/morfik# netstat -tupan Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp0 0 192.168.10.10: 0.0.0.0:* LISTEN 483/mysqld tcp6 0 0 :::80 :::*LISTEN 511/apache2 tcp6 0 0 :::22 :::*LISTEN 1/systemd tcp6 0 0 :::443 :::*LISTEN 511/apache2 Nothing listens on the port 23, why? Still inside of the container: root@www:/home/morfik# tree /etc/systemd/system /etc/systemd/system |-- getty.target.wants | `-- getty@tty1.service - /lib/systemd/system/getty@.service |-- multi-user.target.wants | |-- cron.service - /lib/systemd/system/cron.service | |-- remote-fs.target - /lib/systemd/system/remote-fs.target | `-- rsyslog.service - /lib/systemd/system/rsyslog.service
Re: [systemd-devel] Mediacast to TV - MiracleCast - Open-Source Miracast - Wifi-Display on linux
On Wed, 2015-02-04 at 00:47 +0100, poma wrote: On 03.02.2015 18:43, David Herrmann wrote: Hi On Tue, Feb 3, 2015 at 6:36 PM, poma pomidorabelis...@gmail.com wrote: On 02.02.2015 19:58, David Herrmann wrote: As I'm not really interested in hacking on network-managers, I've decided to stop working on MiracleCast. If, some day, there's a working P2P stack on linux, I might resurrect it. But it sounds more likely that I'll refer to the Intel solution (WYSIWIDI) instead. There're also gstreamer plugins for WFD now, so maybe give them a try? gst-rtsp-server-wfd https://github.com/Samsung/gst-rtsp-server-wfd/blob/master/README.md Pre-conditions: This module is running on established p2p connection with wifi direct, which means that you have to setup this network environment to run this module. I hope this link would be very helpful. ( http://cgit.freedesktop.org/~dvdhrm/miracle ) You are referring to them, they are referring to you. :) They provide a gstreamer plugin for Miracast, but quite frankly didn't bother hacking on Wifi P2P. Hence, they refer to my miracle-wifid hack to provide a P2P link. If NM provides a P2P API, you can just set it up via nmcli and then use the gst modules to run Miracast (or you can just use the ConnMan API right now). Thanks David Well at least there is an open RFE - Network Manager [enh] Add support for WiFi P2P (aka WiFi Direct) https://bugzilla.gnome.org/show_bug.cgi?id=734073 And in this thread I see Patrik Flykt - ConnMan. Connman WiFi p2p API evaluation https://mail.gnome.org/archives/networkmanager-list/2015-January/msg00018.html Let's see if NetworkMan can learn from ConnMan. :) Of course it can learn something :) We'd rather have NetworkManager share an API with ConnMan here instead of needlessly re-inventing the wheel. I think we came to quasi-agreement in the mail thread you link to, but need to write up a final spec and get agreement from Patrik. This might also be a good project for a community member to help out with too. So if anyone is interested in the NetworkManager side of P2P/Direct (and I know some are) please raise your hand! Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] hwdb: Bind toolbox buttons to the Windows key
On Wed, Feb 04, 2015 at 06:46:10PM +0100, Bastien Nocera wrote: One would expect pressing the button to go to an overview / show applications mode, we thus map it to leftmeta, the Windows key. See https://bugzilla.gnome.org/show_bug.cgi?id=658602#c17 Applied. Zbyszek KEYBOARD_KEY_6c=direction # rotate - KEYBOARD_KEY_68=f13# toolbox + KEYBOARD_KEY_68=leftmeta # toolbox KEYBOARD_KEY_6b=esc# escape KEYBOARD_KEY_6d=right # right on d-pad KEYBOARD_KEY_6e=left # left on d-pad @@ -601,7 +601,7 @@ keyboard:dmi:bvn*:bvr*:bd*:svnLENOVO*:pnThinkPad*X6*:pvr* # ThinkPad X41 Tablet keyboard:dmi:bvn*:bvr*:bd*:svnIBM*:pn18666TU:pvr* KEYBOARD_KEY_6c=direction # rotate - KEYBOARD_KEY_68=f13# toolbox + KEYBOARD_KEY_68=leftmeta # toolbox KEYBOARD_KEY_6b=esc# escape KEYBOARD_KEY_69=enter # enter on d-pad ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv2 1/4] systemctl: cat, edit: improve unit load error reporting
Looks good. Pushed all four.
Zbyszek
On Thu, Feb 05, 2015 at 01:56:57AM +0300, Ivan Shapovalov wrote:
- report actual load error for units which could not be loaded
- make unit_find_paths() report all kinds of errors it encounters
(for consistency)
- consistently handle not-found errors in cat() and edit()
---
src/systemctl/systemctl.c | 54
+++
1 file changed, 40 insertions(+), 14 deletions(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 462f7fd..083b618 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -2309,9 +2309,12 @@ static int unit_find_paths(sd_bus *bus,
if (!avoid_bus_cache !unit_name_is_template(unit_name)) {
_cleanup_bus_error_free_ sd_bus_error error =
SD_BUS_ERROR_NULL;
+_cleanup_bus_message_unref_ sd_bus_message *unit_load_error
= NULL;
_cleanup_free_ char *unit = NULL;
_cleanup_free_ char *path = NULL;
_cleanup_strv_free_ char **dropins = NULL;
+_cleanup_strv_free_ char **load_error = NULL;
+char *unit_load_error_name, *unit_load_error_message;
unit = unit_dbus_path_from_name(unit_name);
if (!unit)
@@ -2320,6 +2323,31 @@ static int unit_find_paths(sd_bus *bus,
if (need_daemon_reload(bus, unit_name) 0)
warn_unit_file_changed(unit_name);
+r = sd_bus_get_property(
+bus,
+org.freedesktop.systemd1,
+unit,
+org.freedesktop.systemd1.Unit,
+LoadError,
+error,
+unit_load_error,
+(ss));
+if (r 0)
+return log_error_errno(r, Failed to get LoadError:
%s, bus_error_message(error, r));
+
+r = sd_bus_message_read(
+unit_load_error,
+(ss),
+unit_load_error_name,
+unit_load_error_message);
+if (r 0)
+return bus_log_parse_error(r);
+
+if (!isempty(unit_load_error_name)) {
+log_error(Unit %s is not loaded: %s, unit_name,
unit_load_error_message);
+return 0;
+}
+
r = sd_bus_get_property_string(
bus,
org.freedesktop.systemd1,
@@ -2387,6 +2415,9 @@ static int unit_find_paths(sd_bus *bus,
r = unit_file_find_dropin_paths(lp-unit_path, NULL,
names, dropin_paths);
}
+if (r == 0)
+log_error(No files found for %s., unit_name);
+
return r;
}
@@ -4588,10 +4619,8 @@ static int cat(sd_bus *bus, char **args) {
r = unit_find_paths(bus, *name, avoid_bus_cache, lp,
fragment_path, dropin_paths);
if (r 0)
return r;
-else if (r == 0) {
-log_warning(Unit %s does not have any files on
disk, *name);
-continue;
-}
+else if (r == 0)
+return -ENOENT;
if (first)
first = false;
@@ -5940,9 +5969,13 @@ static int find_paths_to_edit(sd_bus *bus, char
**names, char ***paths) {
r = unit_find_paths(bus, *name, avoid_bus_cache, lp, path,
NULL);
if (r 0)
return r;
-else if (r == 0 || !path)
+else if (r == 0)
+return -ENOENT;
+else if (!path) {
// FIXME: support units with path==NULL (no
FragmentPath)
-return log_error_errno(ENOENT, Unit %s not found,
cannot edit., *name);
+log_error(No fragment exists for %s., *name);
+return -ENOENT;
+}
if (arg_full)
r = unit_file_create_copy(*name, path, user_home,
user_runtime, new_path, tmp_path);
@@ -5981,19 +6014,12 @@ static int edit(sd_bus *bus, char **args) {
if (r 0)
return log_error_errno(r, Failed to expand names: %m);
-if (!names) {
-log_error(No unit name found by expanding names);
-return -ENOENT;
-}
-
r = find_paths_to_edit(bus, names, paths);
if (r 0)
return r;
-if (strv_isempty(paths)) {
-
[systemd-devel] udev rules fails to set attribute on boot on CentOS 6.6
Hi guys,
I'm not exactly sure if I'm asking the right question in the right
place, please let me know if this is not the right place for this question.
I'm setting up SR-IOV for my Intel I350 igb on CentOS 6.6
(2.6.32-504.el6.x86_64, udev 147) using udev. I have modified a rule I
used in CentOS 7 (3.10.0-123.el7.x86_64, udev 208). When I do udevadm
test on CentOS 6.6, the rule is matched correctly and sets the
sriov_numvfs attribute to the desired number and enables SR-IOV accordingly:
# cat /etc/udev/rules.d/igbsriov.rules
KERNEL==:01:00.0, SUBSYSTEM==pci, DRIVER==igb,
ATTR{vendor}==0x8086, ATTR{device}==0x1521,
WAIT_FOR=/sys/bus/pci/devices/:01:00.0/sriov_numvfs,
ATTR{sriov_numvfs}=7
However, when the computer is reboot, sriov_numvfs attribute is not set
until I perform udevadm trigger
Any ideas what I may be missing?
Best regards,
Angelos
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] DefaultDependencies=false on scopes
On Tue, 03.02.15 21:03, Brandon Philips (bran...@ifup.co) wrote: Hey Lennart- On Tue, Feb 3, 2015 at 10:32 AM, Brandon Philips bran...@ifup.co wrote: On Tue, Feb 3, 2015 at 10:20 AM, Lennart Poettering lenn...@poettering.net wrote: I have added DefaultDependencies= for you now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=261420ba2a20305ad271b6f5f380aa74c5c9dd50 Thank you. I will work on getting Docker fixed up to fix this annoying behavior. So, is this the best way to tell if the systemd I am working with supports setting this property on a scope? https://github.com/philips/libcontainer/blob/systemd-default-dependencies-false/cgroups/systemd/apply_systemd.go#L74 Hmm, I figure I am not hipster enough to read this Go code... But yeah, if you check for ReadOnlyProperty when putting together a scope, that sounds like an OK check. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Make seccomp protections in systemd-nspawn optional
On Wed, 04.02.15 02:21, Jay Faulkner (j...@jvf.cc) wrote: I am not particularly fond of the idea of adding a completely new command line option for this though. Maybe we can find another way for this. For example, one option could be to split the seccomp syscall blacklist in two: split out the kernel kmod related syscalls, and only add them to the seccomp filter if arg_retain does not include CAP_SYS_MODULE. This would then leave the module seccomp filters in place by default, however, if you add the CAP_SYS_MODULE cap to the container with --capability= then the seccomp filter is changed to also allow the module loading sys calls. I implemented this; the patch can be pulled directly from https://github.com/jayofdoom/systemd/pull/2.patch to prevent me from corrupting this along the way. Applied, thanks! As a note; unlike what we discussed in IRC, someone passing capability=all will be covered for module loading in this situation, because all sets the bitmask to -1, effectively enabling all capabilities. Yupp, I thought that was pretty much what I was saying on IRC. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
On Wed, 04.02.15 10:08, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello all, a little while ago, Jon Severinsson wrote a sysv generator optimization to not go through all the parsing of init.d scripts and creation of units if there already is a native unit for that name. As they are put into generator.late they would be ignored anyway. Well, but their enablement status so far is not ignored. i.e. if you drop in a unit file, as well as a sysv script, and the latter is enabled, but the former not, then systemd currently reads that so that the sysv one is overriden by the native one, and the native one is considered enabled. With this change you alter that behaviour. Is that really desired? (Not saying it wasn't desired, just pointing out the difference, and asking for some consideration of this issue?) This is particularly relevant if you have lots of init.d scripts, like we have on Debian. Other than that it's not a behaviour change AFAICS. I cleaned it up a bit and added a test case. One thing I wonder about is whether native_unit_exists() should perhaps be moved into src/shared/? It might be useful for other stuff. We have similar code in src/shared/install.c already, this should really be unified... I must say I kinda like the fact though that the sysv generator knows nothing about native units so far... Anyway, not totally opposed, but I'd like to hear some analysis first why this change in behaviour does not matter. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Container, private network and socket activation
On Wed, 04.02.15 04:40, Mikhail Morfikov (mmorfi...@gmail.com) wrote: 1. When I try to connect for the very first time, I get a timeout, even though the container is working. I can cancel the connection immediately, and reconnect after 2-3 sec and then the page shows up. All subsequent connections work without a problem, just the first one gets a timeout. Is there a way to fix this, so the first connection that boots the system could be somehow delayed, so after a while the page would show up? That indicates that the systemd or apache inside the container do not correctly make use of the the socket passed into them. You need to make sure that inside the container you have pretty much the same .socket unit running as on the host. The ListStream lines must be identical, so that systemd inside the container recognizes the sockets passed in from the host as the ones to use for apache. The only difference for the socket units is that on the host they should activate the container, in the container they should activate apache. 2. Is there a way to shut down the container automatically after some period of inactivity? Let's say there's no traffic for 30min, and after this time the container goes down. No, this is not available. It's hard to know when a process is idle from the outside. While some strategies here are thinkable, no code for it exists. 3. How to stop the container manually? I'm asking because when I try via systemctl stop mycontainer.service , it stops, but: ... Feb 04 04:15:58 morfikownia systemd-nspawn[14346]: Halting system. Feb 04 04:15:58 morfikownia systemd-machined[14353]: Machine debian-tree terminated. Feb 04 04:15:58 morfikownia systemd-nspawn[14346]: Container debian-tree has been shut down. Feb 04 04:15:58 morfikownia systemd[1]: Starting My little container... Well, because the socket wasn't passed on right the connection on it will still be queued after the container exits again. systemd will thus immediately spawn the container again. Basically, if you fix your issue #1, your issue #3 will be magically fixed too. 4. Is there a way to persist the interfaces (veth0 and veth1)? Because after the container goes down, they're deleted, so I have to create them anew. Hmm, good question. I don't think the kernel allows that... It destroys veth links when either side's network namespace dies... Not sure if we can do anything about this in a robust way... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysctl: consider --prefix while parsing the files
On Wed, 04.02.15 10:43, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote:
not while applying the parsed sysctl values. Otherwise
info Overwriting earlier assignment of %s in file %s is
visible many times even though the given --prefix doesn't
try to set the overridden value.
Looks conceptually OK. A few notes:
k = write_string_file(p, value);
if (k 0) {
log_full(k == -ENOENT ? LOG_DEBUG : LOG_WARNING,
@@ -173,6 +157,24 @@ static int parse_file(Hashmap *sysctl_options, const
char *path, bool ignore_eno
p = normalize_sysctl(strstrip(p));
value = strstrip(value);
+if (!strv_isempty(arg_prefixes)) {
+char **i, *t;
+bool good = false;
+STRV_FOREACH(i, arg_prefixes) {
+t = *i;
+if (startswith(t, /proc/sys/)) {
+t = t + strlen(/proc/sys/);
+}
Please use path_startswith() jhere.
Also, startswith() and path_startswith() actually return a pointer to
the first char after the spefied prefix. If you want to skip the
prefix anyway, it's nice to use that.
Also, please no {} around singl-line code blocks.
+if (path_startswith(p, t)) {
+good = true;
+break;
+}
+}
+if (!good) {
+continue;
+}
No {} around single-line code blocks.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Restart sequence: systemctl restart rsyslog.service syslog.socket often/sometimes fails
First: Please let me know if this is an inappropriate place to ask this # systemctl restart syslog.socket rsyslog.service seems to always work. But # systemctl restart rsyslog.service syslog.socket , the opposite sequence, seems to sometimes fail (details below). I'm wondering: Why is that? And if I have a list of 20 PATTERNs, how do I devise the magical pattern that ALWAYS works? man systemctl[1] seems not to mention anything about sequence of PATTERN...s. Depending on what hardware I try it occurs always, often, sometimes or rarely. But trying it e.g. 1000 times seems to always trigger it at sometimes. (A little scary that it doesn't always produce the same result!!!) BACKGROUND I'm not quite certain that there is a need to restart syslog.socket too. Let me know if that is the case. But the question is still broader: How is the sequence of PATTERN...s relevant for restart and how do I create a good sequence (even if we omit syslog.socket). Our app uses a number of system services (apache2, syslog-ng, mysql, rabbitmq-server and some more). We have a randomly ordered list of them. (Note we're actually using syslog-ng but the same ordering issue also applies for rsyslog as shown above) When we restore from a backup, we stop these services, put restored data in place and start them again. Because of debian issue #751744: dh-systemd: postinst snippets should stop foo.socket during upgrades too, syslog.socket is also in our list or it sometimes starts up before we're done. When we change configuration files, we restart that same list of names. So also syslog.socket. DETAILS === root@capmon:~# journalctl -xn --show-cursor -l --no-pager | tail -n 1 -- cursor: s=7cdc228fff4d49ada9fbebdfaf72e357;i=7a3;b=916402c8a5c747938b040a03c16b0e60;m=9e7556e8;t=50e404b5811ad;x=59fdfb3b30d4bdfa root@capmon:~# systemctl restart rsyslog.service syslog.socket Job for syslog.socket failed. See 'systemctl status syslog.socket' and 'journalctl -xn' for details. A dependency job for rsyslog.service failed. See 'journalctl -xn' for details. root@capmon:~# journalctl -xn --after-cursor='s=7cdc228fff4d49ada9fbebdfaf72e357;i=7a3;b=916402c8a5c747938b040a03c16b0e60;m=9e7556e8;t=50e404b5811ad;x=59fdfb3b30d4bdfa' -l --no-pager -- Logs begin at Wed 2015-02-04 10:18:51 CET, end at Wed 2015-02-04 11:06:42 CET. -- Feb 04 11:06:42 capmon systemd[1]: Stopping System Logging Service... -- Subject: Unit rsyslog.service has begun shutting down -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit rsyslog.service has begun shutting down. Feb 04 11:06:42 capmon systemd[1]: Starting Syslog Socket. -- Subject: Unit syslog.socket has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit syslog.socket has begun starting up. Feb 04 11:06:42 capmon systemd[1]: Listening on Syslog Socket. -- Subject: Unit syslog.socket has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit syslog.socket has finished starting up. -- -- The start-up result is done. Feb 04 11:06:42 capmon systemd[1]: Starting System Logging Service... -- Subject: Unit rsyslog.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit rsyslog.service has begun starting up. Feb 04 11:06:42 capmon systemd[1]: Stopping Syslog Socket. -- Subject: Unit syslog.socket has begun shutting down -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit syslog.socket has begun shutting down. Feb 04 11:06:42 capmon systemd[1]: Starting Syslog Socket. -- Subject: Unit syslog.socket has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit syslog.socket has begun starting up. Feb 04 11:06:42 capmon systemd[1]: Socket service rsyslog.service already active, refusing. Feb 04 11:06:42 capmon systemd[1]: Failed to listen on Syslog Socket. -- Subject: Unit syslog.socket has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit syslog.socket has failed. -- -- The result is failed. Feb 04 11:06:42 capmon systemd[1]: Dependency failed for System Logging Service. -- Subject: Unit rsyslog.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit rsyslog.service has failed. -- -- The result is dependency. root@capmon:~# systemctl status syslog.socket -l syslog.socket - Syslog Socket Loaded: loaded (/lib/systemd/system/syslog.socket; static) Active: inactive (dead) since Wed 2015-02-04 11:06:42 CET; 2min 58s ago Docs: man:systemd.special(7) http://www.freedesktop.org/wiki/Software/systemd/syslog Listen: /run/systemd/journal/syslog
Re: [systemd-devel] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]
On Wed, 04.02.15 08:56, Martin Pitt (martin.p...@ubuntu.com) wrote: Lennart Poettering [2015-02-03 21:40 +0100]: It's really about synchronous waiting on jobs. If you synchronously wait for completion of jobs that are ordered against the job your are part of yourself, then things will deadlock. Indeed. The problem is that if you reload e. g. postfix from a DHCP or network up/down hook, such a script doesn't have the slightest idea whether it was run because the network changed at runtime (i. e. udev event or the user just selected a new network) or whether it happens as part of a systemd transaction (boot/shutdown). In the former case you do want to block, in the latter case you mustn't. I don't see why you'd want to block in either case. Networking is asynchronous anyway, there's really no point in blocking here. What does this give you? Modern code, that talks directly to systemctl, that uses hook scripts, should always use --no-block for these cases. That said, non-crap code does not rely on hook scripts like this anyway, and just subscribes to rtnl on its own. Now, regardless which option you choose it's always a good idea to keep this change as local as possible. Altering the state engine for all operations is the worst solution... Well, it's a problem which can happen in a lot of scenarios and isn't specific to which kind of service or hook script you have, so what's local is actually quite hard to define here. I agree with Michael that involving a lot of shell commands which we then have to copy to lots of places (and find these places at all) is also not the best solution. So perhaps we could have some middle ground here and make systemctl a bit more clever? Hmm? I don't follow here at all? I mean, you must have some code in Debian that forwards old sysv restart/reload requests to systemctl. That's probably going to be in /usr/sbin/service and maybe a few other places. Why can't you just add the --no-block logic there, conditionalized to shutdown/reboot? - Don't enqueue a reload if the service to be reloaded isn't running. E. g. postfix.service inactive/dead in https://bugs.debian.org/635777 or smbd.service start/waiting in https://launchpad.net/bugs/1417010. This would completely avoid the deadlock in most situations already, and doesn't change the semantics for working use cases either, so this should even be applicable for upstream? No, this would open up the door for races. The guarantee we give around blocking operations, is that by the time they return the operation or an equivalent has been executed. More specifically, if you start a service, and it is in starting, and then issue a reload or restart, and it returns you *know* that the configuration that was on disk at the time you issued the reload or restart -- or a newer one -- is in place. If you'd suppress the reload/restart in this case, then you will not get that guarantee, because the configuration ultimately loaded might be the one from the time the daemon was first put into starting mode at. Or in other words: if a script does this: # sed -i -e 's/something/somethingelse/' /etc/mydaemon.conf # systemctl restart mydaemon.service Then we *must* give the guarantee that when the second command returns the change just made to /etc/mydaemon.conf is in place, and not a previous config loaded. And we must guarantee that in any case, regardless if the daemon is about to start, already started, reloaded or anything else... (Now, this example is about restarts, but reload is pretty much the same, except that many people use async ExecReload= commands (for example send a signal), which will break this guarantee, but that's on them then, we recommend synchronous reload operations, to make this race-free). And/or - systemctl reload/restart could imply --no-block if the service is already enqueued in the current transaction. That would avoid this deadlock situation in more cases. Opens the same race, as described above. Also: *why* for heaven's sake? Just add --no-block when you are running from these contexts, and all is good. I really don't get why you don't want to do that. With that the remaining deadlock case would be trying to reload an already running service which isn't affected by the current transaction, but we haven't seen that in practice yet. If you don't want this upstream, I'd keep it as a patch in Debian. But I can't really imagine that this wouldn't happen in Fedora or other distros? I mean, things like the ISC DHCP hooks aren't a Debianism, and a lot of existing software wasn't written with this be careful on service reloads and guess whether you need --no-block approach in mind, as it has never been a problem with other init systems. On Fedora, these hook scripts use --no-block correctly, and I am completely puzzled why you don't want this on Debian! Please, can you elaborate what your issue with --no-block is? Lennart
Re: [systemd-devel] Restart sequence: systemctl restart rsyslog.service syslog.socket often/sometimes fails
On Wed, 04.02.15 11:13, Peter Valdemar Mørch (pe...@morch.com) wrote: First: Please let me know if this is an inappropriate place to ask this # systemctl restart syslog.socket rsyslog.service seems to always work. But # systemctl restart rsyslog.service syslog.socket , the opposite sequence, seems to sometimes fail (details below). I'm wondering: Why is that? Whats are the precise ordering and requirement deps between those two services? Note that the command will first enqueue the restart job for the first mentioned service, then the restart job for the second service. It will then wait for both jobs to complete. Depending on the deps it might happen in the second case, that the service is first stopped, and then the socket stopped, and then the service started again. Now, when the socket is about to be started again too, the service will already be up, but in non-socket-activation mode, at which point the socket unit refuses to start up, in order to not corrupt the socket the service created on its own without usage of socket activation. This is something that can be fixed by adding stricter deps between the service and the socket, so that the socket is always required to be started before the service. Something for the respective package maintainers upstream to fix. Alternatively, only restart the service, don't bother with the socket... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] slow systemd-networkd DHCP client on wlan0 with systemd v217
Hi, On Tue, 2015-02-03 at 17:27 +0100, Lennart Poettering wrote: Is the resume event detected somehow in systemd? The kernel unfortunately provides no API for this right now. However, if logind is the one suspending the machine, then it sends out a PrepareForSleep() signal before doing so. systemd-resolved already hooks into that: http://cgit.freedesktop.org/systemd/systemd/tree/src/resolve/resolved-bus.c#n684 Tom mentioned he's already looking into adding similar code to networkd to handle this properly. Latest upstream works fine for me. Links break at suspend and are enabled at restore with PrepareForSleep() handled. Both versions of DHCP properly stop and start at these events. Cheers, Patrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
Hey, Lennart Poettering [2015-02-04 13:42 +0100]: Well, but their enablement status so far is not ignored. i.e. if you drop in a unit file, as well as a sysv script, and the latter is enabled, but the former not, then systemd currently reads that so that the sysv one is overriden by the native one, and the native one is considered enabled. With this change you alter that behaviour. Is that really desired? Since it's rather confusing what happens in this case, we made systemctl sync the status to update-rc.d (the chkconfig equivalent in Debian) on enable/disable: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/systemctl-don-t-skip-native-units-when-enabling-disa.patch That of course doesn't change the behaviour with manual rc?.d/ symlinks. But if you have a native unit, I think it's rather unexpected if you disable it with systemctl, enable it in sysv, but still get it started. It seems to me that systemctl disable should win here -- after all, that's closer to the running systemd than the rc.d links. So in that regard it would be an intended behaviour change indeed. But either way this is a corner case for sure. I just wouldn't like to carry this patch forever as it's relatively unimportant. Maybe Jon can chime in about his intentions with this? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?
On 02/02/15 20:49, Lennart Poettering wrote: BTW, just to mention this. You can also just write: # systemctl start /home/myuser/data That's good to know, thanks. This will automatically be translated to home-myuser-data.mount. systemctl has some logic built in to translate strings that don't look like unit names into unit names. Essentially this hence means that this: a) mount /home/myuser/data b) systemctl start /home/myuser/data However, the latter respects the whole systemde depency logic, while the former just tries to mount the specified dir immediately, ignoring all deps. yep, got that now. mount doesn't hit-up systemd so the deps don't happen. I'll train my mind to remember option (b). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]
Lennart Poettering [2015-02-04 13:27 +0100]: On Wed, 04.02.15 08:56, Martin Pitt (martin.p...@ubuntu.com) wrote: Lennart Poettering [2015-02-03 21:40 +0100]: It's really about synchronous waiting on jobs. If you synchronously wait for completion of jobs that are ordered against the job your are part of yourself, then things will deadlock. Indeed. The problem is that if you reload e. g. postfix from a DHCP or network up/down hook, such a script doesn't have the slightest idea whether it was run because the network changed at runtime (i. e. udev event or the user just selected a new network) or whether it happens as part of a systemd transaction (boot/shutdown). In the former case you do want to block, in the latter case you mustn't. I don't see why you'd want to block in either case. Networking is asynchronous anyway, there's really no point in blocking here. What does this give you? So far, if a hook or shell script calls e. g. service foo restart, it can count on the service actually being reloaded after it finishes, and thus you can then interact with it immediately. That's not important for many scripts, but we can't just always make service foo reload async by using --no-block, as that would break compatibility with scripts which do rely on that behaviour. So we do need to conditionalize it to avoid the deadlocks under systemd. Modern code, that talks directly to systemctl, that uses hook scripts, should always use --no-block for these cases. Yeah, for sure. We just don't have that luxury easily, as first these scripts don't call systemctl but service (for the Debianists: or invoke-rc.d, but same difference), it will take some time to find all these occurrences, and people will hate us for having to add stuff like if (running under systemd) systemctl --no-block reload foo else service foo reload as that special case appears rather pointless for someone who hasn't dealt with the details of systemd job transactions. That's not to say that it shouldn't happen (perhaps adding a --no-block option to service), but that takes time. I mean, you must have some code in Debian that forwards old sysv restart/reload requests to systemctl. That's probably going to be in /usr/sbin/service and maybe a few other places. Why can't you just add the --no-block logic there, conditionalized to shutdown/reboot? Well, we can; it's just as much an unreliable hack as the two existing patches :-) and I was wondering if we can't solve this in a more generic/distro agnostic way. - Don't enqueue a reload if the service to be reloaded isn't running. E. g. postfix.service inactive/dead in https://bugs.debian.org/635777 or smbd.service start/waiting in https://launchpad.net/bugs/1417010. This would completely avoid the deadlock in most situations already, and doesn't change the semantics for working use cases either, so this should even be applicable for upstream? No, this would open up the door for races. The guarantee we give around blocking operations, is that by the time they return the operation or an equivalent has been executed. More specifically, if you start a service, and it is in starting, and then issue a reload or restart, and it returns you *know* that the configuration that was on disk at the time you issued the reload or restart -- or a newer one -- is in place. If you'd suppress the reload/restart in this case, then you will not get that guarantee, because the configuration ultimately loaded might be the one from the time the daemon was first put into starting mode at. Hm, I don't quite understand this. If you reload a service which isn't currently running, systemctl will fail. It's just currently going to enqueue the reload request, and executing the job will fail due to the not active check in unit_reload(). The problem with that is just that systemctl doesn't fail immediately with the unit is not active, but blocks on the queued request. So if you don't have pending jobs, the net result is the same, but with pending jobs you can easily get a deadlock. Or in other words: if a script does this: # sed -i -e 's/something/somethingelse/' /etc/mydaemon.conf # systemctl restart mydaemon.service Then we *must* give the guarantee that when the second command returns the change just made to /etc/mydaemon.conf is in place, and not a previous config loaded. Yes, that's fine. I only said reload above, as that's what DHCP/network scripts usually do. (Now, this example is about restarts, but reload is pretty much the same reload on an inactive unit will fail, restart will start it. Also: *why* for heaven's sake? Just add --no-block when you are running from these contexts, and all is good. I really don't get why you don't want to do that. Well, I do, but special-casing that on boot/shutdown isn't enough (you can have other bigger transactions which lock up); and it's rather expensive to do
Re: [systemd-devel] /proc and /sys get unmounted during boot from NFS, which results in boot error
Hey!
Maybe something from your initrd is acting weird?
As far as I can tell, nothing from the initrd is running. It's
basically ArchLinux's mkinitcpio run on gentoo - thus, pretty standard stuff.
It might be interesting to strace PID 1 while you are doing this. And
if that doesn't help strace the other processes you run, to see if any
of them unmounts anything.
Good idea! Actually, I found out some more stuff.
1. It's not calling ls /proc, it seems as if the auto-complete
function of the running shell triggers the problem.
2. It's not restricted to auto-completing /proc, /home triggers it as
well.
3. But it's not bash's fault, tcsh triggers it, too.
4. Auto-completing one level deeper, e.g. /usr/bin, doesn't trigger
the unmount.
( note: I've two shells running: one started by the emergency shell and
one started by the small dropbear server I manually started
for debugging purpose. Everything but dropbear is watched by strace.
The problem, of course, also occurs without dropbear.)
$ strace -f -F -p 1 -p 179 -p191 -p177
Process 1 attached
Process 179 attached
Process 191 attached
Process 177 attached
[pid 177] wait4(-1, unfinished ...
[pid 191] rt_sigsuspend([] unfinished ...
[pid 179] read(16, unfinished ...
[pid 1] fstat(14, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
[pid 1] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x7faf0bd52000
[pid 1] read(14, strace\n, 1024) = 7
[pid 1] close(14) = 0
[pid 1] munmap(0x7faf0bd52000, 4096) = 0
[pid 1] writev(3, [{31, 4}, {systemd, 7}, {[1]: , 5}, {Child 202
(strace) died (code=ex..., 55}, {\n, 1}], 5) = 72
[pid 1] open(/proc/202/cgroup, O_RDONLY|O_CLOEXEC) = 14
[pid 1] fstat(14, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
[pid 1] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x7faf0bd52000
[pid 1] read(14, 8:memory:/\n7:freezer:/\n6:devices..., 1024) = 101
[pid 1] close(14) = 0
[pid 1] munmap(0x7faf0bd52000, 4096) = 0
[pid 1] waitid(P_PID, 202, {si_signo=SIGCHLD, si_code=CLD_EXITED,
si_pid=202, si_status=0, si_utime=0, si_stime=0}, WEXITED, NULL) = 0
[pid 1] waitid(P_ALL, 0, {}, WNOHANG|WEXITED|WNOWAIT, NULL) = 0
[pid 1] epoll_wait(4, unfinished ...
[pid 179] ... read resumed \n, 1) = 1
[...]
( this was the only output from systemd, so I guess it's not guilty).
auto-completing /proc
[pid 179] rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
[pid 179] write(2, l, 1)= 1
[pid 179] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 179] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid 179] read(0, s, 1) = 1
[pid 179] rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
[pid 179] write(2, s, 1)= 1
[pid 179] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 179] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid 179] read(0, , 1) = 1
[pid 179] rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
[pid 179] write(2, , 1)= 1
[pid 179] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 179] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid 179] read(0, /, 1) = 1
[pid 179] rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
[pid 179] write(2, /, 1)= 1
[pid 179] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 179] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid 179] read(0, p, 1) = 1
[pid 179] rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
[pid 179] write(2, p, 1)= 1
[pid 179] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 179] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid 179] read(0, r, 1) = 1
[pid 179] rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
[pid 179] write(2, r, 1)= 1
[pid 179] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 179] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid 179] read(0, o, 1) = 1
[pid 179] rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
[pid 179] write(2, o, 1)= 1
[pid 179] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 179] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid 179] read(0, \t, 1)= 1
### tab is pushed here
[pid 179] openat(AT_FDCWD, /, O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
[pid 179] getdents(3, /* 22 entries */, 32768) = 560
[pid 179] getdents(3, /* 0 entries */, 32768) = 0
[pid 179] close(3)= 0
[pid 179] stat(/proc, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 179] rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
[pid 179] write(2, c/, 2)
# after a reboot: autocomplete, that doesn't trigger
[pid 179] read(0, \t, 1)= 1
[pid 179] stat(/usr, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 179] openat(AT_FDCWD, /usr/,
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
[pid 179] getdents(3, /* 16 entries */, 32768) = 464
[pid 179] getdents(3, /* 0 entries */,
[systemd-devel] [PATCHv2] sysctl: consider --prefix while parsing the files
not while applying the parsed sysctl values. Otherwise
info Overwriting earlier assignment of %s in file %s is
visible many times even though the given --prefix doesn't
try to set the overridden value.
---
src/sysctl/sysctl.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/src/sysctl/sysctl.c b/src/sysctl/sysctl.c
index 973e67e..b22aff5 100644
--- a/src/sysctl/sysctl.c
+++ b/src/sysctl/sysctl.c
@@ -78,22 +78,6 @@ static int apply_sysctl(const char *property, const char
*value) {
n = stpcpy(p, /proc/sys/);
strcpy(n, property);
-if (!strv_isempty(arg_prefixes)) {
-char **i;
-bool good = false;
-
-STRV_FOREACH(i, arg_prefixes)
-if (path_startswith(p, *i)) {
-good = true;
-break;
-}
-
-if (!good) {
-log_debug(Skipping %s, p);
-return 0;
-}
-}
-
k = write_string_file(p, value);
if (k 0) {
log_full(k == -ENOENT ? LOG_DEBUG : LOG_WARNING,
@@ -173,6 +157,22 @@ static int parse_file(Hashmap *sysctl_options, const char
*path, bool ignore_eno
p = normalize_sysctl(strstrip(p));
value = strstrip(value);
+if (!strv_isempty(arg_prefixes)) {
+char **i, *t;
+bool good = false;
+STRV_FOREACH(i, arg_prefixes) {
+t = path_startswith(*i, /proc/sys/);
+if (t == NULL)
+t = *i;
+if (path_startswith(p, t)) {
+good = true;
+break;
+}
+}
+if (!good)
+continue;
+}
+
existing = hashmap_get2(sysctl_options, p, v);
if (existing) {
if (streq(value, existing))
--
2.1.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v218
On 03/02/15 23:43, Lennart Poettering wrote: The way I understand /usr/local, it is the place where the admin himself places his own scripts and stuff, as extensions for the host OS. Yes, that view is consistent with the FHS (and e.g. Debian Policy's interpretation of the FHS). ./configure --prefix=/usr/local is meant to mostly work for most software, which means it should be possible to hook into systemd, dbus-daemon, etc. by dropping files into /usr/local. The way I understand /usr/local, it is the place where the admin himself places his own scripts and stuff, as extensions for the host OS. Where /opt is the stuff for 3rd party apps (app vendors), and /usr is for 2nd party stuff (OS vendor), /usr/local is for 1st party stuff (admin). That's one version. Many OSs (including Debian and derivatives) have a slightly different interpretation where /usr is the system package manager's territory, regardless of whether the package came from Debian or not - things that came in a .deb go in /usr or occasionally /opt, while things that the sysadmin installed by hand go in /usr/local or occasionally /opt. Installing a .deb is allowed to have arbitrary effects on /usr (subject to the usual policies about not breaking/overwriting other packages without the metadata saying so), but the only thing it's allowed to do in /usr/local is to create/remove empty directories in the maintainer scripts. On Fri, 12.12.14 14:25, Colin Guthrie (gm...@colin.guthr.ie) wrote: It feels very, very odd that /usr/local is being parsed at all here when the --prefix arg does not include it. There's plenty of precedent for including /usr/local/bin in $PATH, /usr/local/share/FOO in search paths, etc., usually before /usr so that local sysadmin changes can override what's provided in the OS. This comes with the obvious caveat that if the local sysadmin breaks things by installing incompatible versions in /usr/local, they get to solve it for themselves. The distinction between modules installed in /usr/local for software also installed in /usr/local and modules installed in /usr/local for software installed in /usr is not new either: in Debian and its derivatives, Python from python.deb looks for modules in .../dist-packages instead of the usual .../site-packages, so that .../site-packages can be reserved for modules that will be loaded into a copy of Python that the sysadmin installed from source. https://wiki.debian.org/Python#Deviations_from_upstream If the were experimenting, but ultimately didn't want to use it, it seems odd to me that the actual packaged version of system would read these files. If they were experimenting with a new version of thermald (picking a random example of something that I have installed in /usr/local in the past), but systemd didn't pick it up, that would be a fairly useless experiment, since it wouldn't actually start :-) If they were experimenting with it but decided not to keep it, that's a good time to remove it from /usr/local. Sysadmins who use /usr/local should really be looking at something like GNU stow to automate installation/removal (or preferably building their local stuff into a .deb/.rpm, at which point it can be in /usr instead). The whole thing is really not thought to the end though. Some folks have /usr/local on NFS, which we cannot handle, since we'll look into it already before NFS is mounted for some things, and never check it again... I think in general this should work, but your configuration is not a supported one is an acceptable response to that, tbh. If a sysadmin wants this badly enough, they can put a hook in their initramfs to mount /usr/local. -- Simon McVittie Collabora Ltd. http://www.collabora.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Restart sequence: systemctl restart rsyslog.service syslog.socket often/sometimes fails
On Wed, 04.02.15 15:53, Peter Valdemar Mørch (pe...@morch.com) wrote: On Wed, Feb 4, 2015 at 2:34 PM, Lennart Poettering lenn...@poettering.net wrote: This is something that can be fixed by adding stricter deps between the service and the socket, so that the socket is always required to be started before the service. Something for the respective package maintainers upstream to fix. So have I understood this correctly: That the order matters *is* a bug. Either in systemd (that provides /lib/systemd/system/syslog.socket) or in syslog-ng and rsyslog that provide e.g. /lib/systemd/system/syslog-ng.service ? The latter. I'm worried that we manually have to figure out the correct ordering of names to systemctl restart PATTERN and would like to be able to rely on systemctl to figure that out for us. Is that a reasonable long-term expectation? (And the reason order/sequence isn't mentioned in the man page?) systemd follows the relations expressed via the deps. If you don't tell systemd the right deps, then things will be executed in any order, and things might not work. I have no idea what they *should* be, but to show what they *are*, here i show for syslog-ng. Seems to me that syslog-ng is clear about syslog.socket being a dependency: It would be a good idea to add Requires=syslog.socket here (or even BindsTo=syslog.socket), as well as After=syslog.socket... cat /lib/systemd/system/syslog-ng.service [Unit] Description=System Logger Daemon Documentation=man:syslog-ng(8) [Service] Type=notify Sockets=syslog.socket ExecStart=/usr/sbin/syslog-ng -F ExecReload=/bin/kill -HUP $MAINPID StandardOutput=null Restart=on-failure Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /proc and /sys get unmounted during boot from NFS, which results in boot error
On Wed, 04.02.15 15:29, Olaf Leidinger (ol...@mescharet.de) wrote: Hey! Maybe something from your initrd is acting weird? As far as I can tell, nothing from the initrd is running. It's basically ArchLinux's mkinitcpio run on gentoo - thus, pretty standard stuff. ps should tell you what else is running when you run into this. So somehow these system calls must trigger the unmount. Probably some process which gets started by systemd performs similar system calls and thus spoils my boot. The dumps you posted show no difference really... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
