Re: [systemd-devel] [PATCH] build-sys: check for intltool also when polkit is enabled
On Thu, Jul 31, 2014 at 2:37 PM, Samuli Suominen wrote: > Isn't this scenario already covered by this existing configure.ac test... > > AS_IF([test -z "$INTLTOOL_POLICY_RULE"], [ > # If intltool is not available, provide a dummy rule to fail > generation of %.policy files with a meaningful error message > INTLTOOL_POLICY_RULE='%.policy: %.policy.in ; @echo " ITMRG " $@ > && echo "*** intltool support required to build target $@" && false' > AC_SUBST(INTLTOOL_POLICY_RULE) > ]) > > ...? This code is actually causing the trouble without my patch in that situation since this code incorrectly assumes that intltool is not available since the previous code was missed out and thus the build fails with a complaint about missing intltool, even when it is available. Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Pairing udev's SYSTEMD_WANTS and systemd's templated units
I suggested something like this in [1] but in the end a systemd-escape
utility was added [2].
Since you can't use ENV to set dynamic variables, you might do that
via a RUN rule instead.
HTH,
Michael
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747044#25
[2] http://lists.freedesktop.org/archives/systemd-devel/2014-July/021050.html
2014-07-31 14:55 GMT+02:00 Ivan Shapovalov :
> Hello all,
>
> I'm trying to start from an udev rule a templated systemd unit, whose instance
> should be a properly escaped device node path (so that %i.device would
> represent
> an existing unit). Which udev specifier should I use for this?
>
> Or, in more clear wording:
>
> given the rule:
>
> ACTION=="add", ..., TAG+="systemd",
> ENV{SYSTEMD_WANTS}+="foo@$some_specifier.service"
>
> and the unit foo@.service:
>
> [Unit]
> After=%i.device
> BindsTo=%i.device
> ...
>
> Which $some_specifier should I use in the udev rule to get %i.device in
> my service file to refer to the valid and corresponding device unit?
>
> The closest match I've got is "sys%p", but it does not work because dashes
> are not
> escaped, and I get
> "sys-devices-pci:00-:00:1d.0-usb4-4-1-4-1.2.device"
> instead of
> "sys-devices-pci:00-:00:1d.0-usb4-4\x2d1-4\x2d1.2.device"
> and so on.
>
> Thanks,
> --
> Ivan Shapovalov / intelfx /
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
--
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 0/5] kdbus: allow multiple policies
On Thu, Jul 31, 2014 at 8:57 PM, Djalal Harouni wrote:
> (Cc'ed Lennart)
>
> On Thu, Jul 31, 2014 at 05:40:53PM +0200, Kay Sievers wrote:
>> On Wed, Jul 23, 2014 at 6:34 PM, Djalal Harouni wrote:
>> > This series adds the infrastructure to test and upload multiple
>> > policies.
>> >
>> > The last #5 patch allows to upload multiple policies per connection
>>
>> What is the reason for this? A policy holding connection (which
>> matches a busname unit) shouldn't only be in charge of one single
>> name?
> Hmm, I thought that what you describe is for activators?
Yes, activators can only ever have one name, but policy holders should too.
> I was following the current kdbus spec/code here!
>
> From kdbus.h source:
> "@KDBUS_HELLO_POLICY_HOLDER: Special-purpose connection which registers
> policy entries for one or multiple names. The provided names are not
> activated, and are not registered with the name database"
I'm going to fix that, it does not sound correct.
We have one .busname file per name and it will get really complicated
to start stop a busname, when it has multiple names per connection. We
should really avoid that and require one connection per name and allow
only name.
> And the logic in policy.c is set that multiple policy entries can have
> the same owner which is the policy holding connection:
>
> struct kdbus_policy_db_entry {
> char *name;
> struct hlist_node hentry;
> struct list_head access_list;
> const void *owner;
> bool wildcard:1;
> };
Only custom endpoints will carry list of policies for different names.
It looks and acts a little bit like a firewall.
> This should allow one single connection to handle multiple policy
> entries, I think the design is good, since policy entries are then
> handled internally by kdbus, so only one single connection resources
> to achieve this, which can be reliable on private domains,buses...
Resources don't really matter here, they are cheap. We need to keep
things simple and robust, and managing lists of names in userspace
when the configuration changes would get really complicated.
> The policy holding connection acts like create policy entries, and
> invalidate them when it is closed!
Yes, all that should already work with systemd.
> Still I see three points here from how much pressure and job should
> the policy holding connection do!
> 1) Register policy entries (handled internally), no communication
> 2) Register policy entries + do basic communication based on ID
> 3) Register policy entries + acquire name or names + do communication
>based on names...
Policy holders and activators can never communicate. Activator
connection can get messages queued, but they cannot be received by the
activator connection.
> All of these points are from the perspective: if the policy holding
> connection dies, all the registered policy entries will go away, thus
> invalidating all communications to the registered names...
>
> Should we care ?
It should all work that way already.
> And for that patch change, it will block activators from having
> multiple names, it will fail, but it will succeed for policy holders.
Which is intentional. Sorry for the misleading text in the docs.
>> > The todo for the policy holders is:
>> >
>> > * Should we set a maximum value for how many names/policies a policy
>> > holder is allowed to upload. This is needed since we do not want to
>> > consume all the entries (kdbus_policy_db->entries_hash).
>>
>> Yes, everything that consumes kernel memory needs to be limited.
> Ok, so this needs a proper discussion, will send about it and Cc Lennart
> too.
We need to limit the size of the uploaded policy, just like we limit
the amount of messages.
> So perhaps do not apply this series until we have a proper limit.
>
>> > * Update/test the kdbus_policy_set() to work with multiple names.
>>
>> This is meant for custom endpoints, not for policy-holder connections?
> Currently it is aimed to work for both of them!
>
> I've tested for policy-holder connections and it works with this series
> applied, but only when we create new connections. It will not work when
> we try to update or register new properties, policies or names.
>
>
> So from the source:
> connection.c:1978 it will fail, but with this patch series it will
> succeed.
>
> connection.c:1801 it will fail in kdbus_cmd_conn_update()
> Since it allows only to add/update one policy entry. So this one will be
> a todo item.
>
> And for custom endpoints, I'm sure that kdbus_policy_set() is broken, and
> it was perhaps never tested since custom endpoints are still broken, we
> can't create them, at least that was the case the last time I checked.
We never tested any of the custom endpoint stuff so far, it is just dead code.
> Kay I'm trying to have a kdbus_policy_set() version only for
> connections, so it will work for policy holding connections that handle
> multiple names! this will help to fix the sending cache issue I'
Re: [systemd-devel] [PATCH 0/5] kdbus: allow multiple policies
(Cc'ed Lennart)
On Thu, Jul 31, 2014 at 05:40:53PM +0200, Kay Sievers wrote:
> On Wed, Jul 23, 2014 at 6:34 PM, Djalal Harouni wrote:
> > This series adds the infrastructure to test and upload multiple
> > policies.
> >
> > The last #5 patch allows to upload multiple policies per connection
>
> What is the reason for this? A policy holding connection (which
> matches a busname unit) shouldn't only be in charge of one single
> name?
Hmm, I thought that what you describe is for activators?
I was following the current kdbus spec/code here!
>From kdbus.h source:
"@KDBUS_HELLO_POLICY_HOLDER: Special-purpose connection which registers
policy entries for one or multiple names. The provided names are not
activated, and are not registered with the name database"
And the logic in policy.c is set that multiple policy entries can have
the same owner which is the policy holding connection:
struct kdbus_policy_db_entry {
char *name;
struct hlist_node hentry;
struct list_head access_list;
const void *owner;
bool wildcard:1;
};
This should allow one single connection to handle multiple policy
entries, I think the design is good, since policy entries are then
handled internally by kdbus, so only one single connection resources
to achieve this, which can be reliable on private domains,buses...
The policy holding connection acts like create policy entries, and
invalidate them when it is closed!
Still I see three points here from how much pressure and job should
the policy holding connection do!
1) Register policy entries (handled internally), no communication
2) Register policy entries + do basic communication based on ID
3) Register policy entries + acquire name or names + do communication
based on names...
All of these points are from the perspective: if the policy holding
connection dies, all the registered policy entries will go away, thus
invalidating all communications to the registered names...
Should we care ?
And for that patch change, it will block activators from having
multiple names, it will fail, but it will succeed for policy holders.
Hope I'm not out of scope!
> > The todo for the policy holders is:
> >
> > * Should we set a maximum value for how many names/policies a policy
> > holder is allowed to upload. This is needed since we do not want to
> > consume all the entries (kdbus_policy_db->entries_hash).
>
> Yes, everything that consumes kernel memory needs to be limited.
Ok, so this needs a proper discussion, will send about it and Cc Lennart
too.
So perhaps do not apply this series until we have a proper limit.
> > * Update/test the kdbus_policy_set() to work with multiple names.
>
> This is meant for custom endpoints, not for policy-holder connections?
Currently it is aimed to work for both of them!
I've tested for policy-holder connections and it works with this series
applied, but only when we create new connections. It will not work when
we try to update or register new properties, policies or names.
So from the source:
connection.c:1978 it will fail, but with this patch series it will
succeed.
connection.c:1801 it will fail in kdbus_cmd_conn_update()
Since it allows only to add/update one policy entry. So this one will be
a todo item.
And for custom endpoints, I'm sure that kdbus_policy_set() is broken, and
it was perhaps never tested since custom endpoints are still broken, we
can't create them, at least that was the case the last time I checked.
Kay I'm trying to have a kdbus_policy_set() version only for
connections, so it will work for policy holding connections that handle
multiple names! this will help to fix the sending cache issue I've been
talking about.
So please, do confirm that a policy holding connection should be able to
register multiple policies for multiple names, before I give it more
time. Thank you!
The kdbus_policy_set() for custom endpoints can be worked out later...
> Thanks,
> Kay
--
Djalal Harouni
http://opendz.org
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] allow systemd to manage loop device partitions
On Thu, Jul 31, 2014 at 4:00 AM, Kevin Wells wrote: > SYSTEMD_READY is currently set to 0 for all loop devices (loop[0-9]*) > that do not have a backing_file. Partitioned loop devices (ex. loop0p1), > however, are matched by this rule and excluded by systemd even though > they are active devices. > > This change adds an additional check to the rule, ensuring that only > top level loop devices (loop[0-9]+$) are excluded from systemd. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/5] kdbus: allow multiple policies
On Wed, Jul 23, 2014 at 6:34 PM, Djalal Harouni wrote: > This series adds the infrastructure to test and upload multiple > policies. > > The last #5 patch allows to upload multiple policies per connection What is the reason for this? A policy holding connection (which matches a busname unit) shouldn't only be in charge of one single name? > The todo for the policy holders is: > > * Should we set a maximum value for how many names/policies a policy > holder is allowed to upload. This is needed since we do not want to > consume all the entries (kdbus_policy_db->entries_hash). Yes, everything that consumes kernel memory needs to be limited. > * Update/test the kdbus_policy_set() to work with multiple names. This is meant for custom endpoints, not for policy-holder connections? Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/5] test: correctly set the 'ret' variable
On Wed, Jul 23, 2014 at 6:34 PM, Djalal Harouni wrote: > Signed-off-by: Djalal Harouni > --- > test/test-kdbus-policy.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: check for intltool also when polkit is enabled
On Thu, Jul 31, 2014 at 03:37:40PM +0300, Samuli Suominen wrote: > > On 31/07/14 15:18, Robert Schiele wrote: > > intltool is needed for nls _and_ polkit, thus the check needs to be > > changed to do the test whenever one of them is enables. > > > > Without this build fails when configured with > > --disable-nls --enable-polkit > > --- > > configure.ac | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/configure.ac b/configure.ac > > index 43b6eef..0802cfc 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -62,7 +62,7 @@ AS_IF([test x"$intltool_found" != xyes], > >]) > > > > AM_NLS > > -AS_IF([test x"$enable_nls" != xno], [ > > +AS_IF([test x"$enable_nls" != xno -o "x$enable_polkit" != xno], [ > > # intltoolize greps for '^(AC|IT)_PROG_INTLTOOL', so it needs to be on > > its own line > > IT_PROG_INTLTOOL([0.40.0]) > > ]) > > Isn't this scenario already covered by this existing configure.ac test... Hm, maybe. But the patch indeed fixes a build with --disable-nls --enable-polkit. Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Pairing udev's SYSTEMD_WANTS and systemd's templated units
Hello all,
I'm trying to start from an udev rule a templated systemd unit, whose instance
should be a properly escaped device node path (so that %i.device would represent
an existing unit). Which udev specifier should I use for this?
Or, in more clear wording:
given the rule:
ACTION=="add", ..., TAG+="systemd",
ENV{SYSTEMD_WANTS}+="foo@$some_specifier.service"
and the unit foo@.service:
[Unit]
After=%i.device
BindsTo=%i.device
...
Which $some_specifier should I use in the udev rule to get %i.device in
my service file to refer to the valid and corresponding device unit?
The closest match I've got is "sys%p", but it does not work because dashes are
not
escaped, and I get
"sys-devices-pci:00-:00:1d.0-usb4-4-1-4-1.2.device"
instead of
"sys-devices-pci:00-:00:1d.0-usb4-4\x2d1-4\x2d1.2.device"
and so on.
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] [PATCH] build-sys: check for intltool also when polkit is enabled
On 31/07/14 15:18, Robert Schiele wrote: > intltool is needed for nls _and_ polkit, thus the check needs to be > changed to do the test whenever one of them is enables. > > Without this build fails when configured with > --disable-nls --enable-polkit > --- > configure.ac | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure.ac b/configure.ac > index 43b6eef..0802cfc 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -62,7 +62,7 @@ AS_IF([test x"$intltool_found" != xyes], >]) > > AM_NLS > -AS_IF([test x"$enable_nls" != xno], [ > +AS_IF([test x"$enable_nls" != xno -o "x$enable_polkit" != xno], [ > # intltoolize greps for '^(AC|IT)_PROG_INTLTOOL', so it needs to be on > its own line > IT_PROG_INTLTOOL([0.40.0]) > ]) Isn't this scenario already covered by this existing configure.ac test... AS_IF([test -z "$INTLTOOL_POLICY_RULE"], [ # If intltool is not available, provide a dummy rule to fail generation of %.policy files with a meaningful error message INTLTOOL_POLICY_RULE='%.policy: %.policy.in ; @echo " ITMRG " $@ && echo "*** intltool support required to build target $@" && false' AC_SUBST(INTLTOOL_POLICY_RULE) ]) ...? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build-sys: check for intltool also when polkit is enabled
intltool is needed for nls _and_ polkit, thus the check needs to be changed to do the test whenever one of them is enables. Without this build fails when configured with --disable-nls --enable-polkit --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 43b6eef..0802cfc 100644 --- a/configure.ac +++ b/configure.ac @@ -62,7 +62,7 @@ AS_IF([test x"$intltool_found" != xyes], ]) AM_NLS -AS_IF([test x"$enable_nls" != xno], [ +AS_IF([test x"$enable_nls" != xno -o "x$enable_polkit" != xno], [ # intltoolize greps for '^(AC|IT)_PROG_INTLTOOL', so it needs to be on its own line IT_PROG_INTLTOOL([0.40.0]) ]) -- 1.8.4.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for pre-restart check
On Jul 31, 2014 12:57 PM, "Reindl Harald" wrote: > Am 31.07.2014 um 02:16 schrieb Colin Guthrie: > > Reindl Harald wrote on 30/07/14 13:34: > >> *how* should that both help in calling "apachectl -t" *before* stop the > >> service and in case of a error-repsonse keep it running? > > > > Note, just for clarity, you don't really want to run such a config test > > when explicitly stopping a service > > i do want that in case it ends in a state where i can't start it afterwards > "systemctl stop X && rsync data; systemctl start X" and go to a coffee is > not that uncommon What if the configuration is fine in the beginning, but another admin breaks it while your rsync is running? -- Mantas Mikulėnas // sent from phone ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for pre-restart check
Am 31.07.2014 um 07:03 schrieb Jóhann B. Guðmundsson: > On 07/31/2014 12:16 AM, Colin Guthrie wrote: >> I think the use case is pretty clear tho'. Config (or general machine >> state) has transitioned from working to broken in the time since the >> service was started and while it's really not a nice situation to find >> yourself in (relying on a running service not crashng!), this at least >> helps avoid nasty consequences for the most part while you work to fix >> things. > > The use case administrator want, is fixing their own lazyness and > incompetence not having to run the configuration syntax checker by > hand after they made changes to the configuration for one of those > handful of daemon/service that actually come with those. strange attitude calling safety "lazyness" and "incompetence" given that you can throw away a lot of things developed in the past 10 years to support the user in many different areas of IT 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] Support for pre-restart check
Am 31.07.2014 um 02:41 schrieb Michael Biebl: > 2014-07-30 14:34 GMT+02:00 Reindl Harald : >> "ExecStopPre" would be better suited as the pre-restart check because >> it would achieve the goal and also prevent stop a service until it's >> configuration is fixed - that catchs cases where you stop something >> for whatever reason and expect it would be started at the next boot > > I don't think that would be a wise thing to do. > If I want to reboot my system, it shouldn't fail to reboot because of > a buggy apache configuration it could simply called and failing ignored in that case systemd knows that the system is at sthut down > Apache should shutdown and simply fail to start on next reboot in that case yes Am 31.07.2014 um 02:16 schrieb Colin Guthrie:> Reindl Harald wrote on 30/07/14 13:34: >> *how* should that both help in calling "apachectl -t" *before* stop the >> service and in case of a error-repsonse keep it running? > > Note, just for clarity, you don't really want to run such a config test > when explicitly stopping a service i do want that in case it ends in a state where i can't start it afterwards "systemctl stop X && rsync data; systemctl start X" and go to a coffee is not that uncommon > that should always succeed IMO (unless you think that "systemctl > kill ..." should be used in such circumstances?) i think so > I really think an ExecRestartPre (or perhaps a more explicit > ExecRestartCheck) would be a more sensible name (ExecStopPre implies it > would run when explicitly stopping which, as noted above, I think is a > bad plan). It wouldn't run when an ExecReload is given explicitly but if > that operation falls back to restart, it would. falls back? how? when i say "systemctl reload" nothing has to trigger a hard restart and even if - in case of a broken config 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] Support for pre-restart check
On 07/31/2014 12:41 AM, Michael Biebl wrote: 2014-07-30 14:34 GMT+02:00 Reindl Harald : "ExecStopPre" would be better suited as the pre-restart check because it would achieve the goal and also prevent stop a service until it's configuration is fixed - that catchs cases where you stop something for whatever reason and expect it would be started at the next boot I don't think that would be a wise thing to do. If I want to reboot my system, it shouldn't fail to reboot because of a buggy apache configuration. Apache should shutdown and simply fail to start on next reboot. Right the solution to this cannot interfere with normal starting and shutdown and wont be solve with introducing yet another Exec* line in one form or another. What is needed to solve this problem ( as in to reliably restart an application ) as far as I can tell is to introduce something like pre restart check which tries to start another instance of the service in an isolated application container, returns true if successful, is enabled per service, perhaps could be extended per container as well and only executed when systemctl restart/reload ( or implemented in try-restart ) $foo is run. Providing patches for anything less then what I mention here above is a waste of time from my point of view since it wont solve the underlying problem. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] bootchart: don't parse /proc/uptime, use CLOCK_BOOTTIME
* systemd-bootchart always parses /proc/uptime, although the
information is unnecessary when --rel specified
* use /proc/uptime is overkill, since Linux 2.6.39 we have
clock_gettime(CLOCK_BOOTTIME, ...). The backend on kernel side is
get_monotonic_boottime() in both cases.
* main() uses "if (graph_start <= 0.0)" to detect that /proc is
available.
This is fragile solution as graph_start is always smaller than zero
on all systems after suspend/resume (e.g. laptops), because in this
case the system uptime includes suspend time and uptime is always
greater number than monotonic time. For example right now difference
between uptime and monotonic time is 37 hours on my laptop.
Note that main() calls log_uptime() (to parse /proc/uptime) for each
sample when it believes that /proc is not available. So on my laptop
systemd-boochars spends all live with /proc/uptime parsing +
nanosleep(), try
strace /usr/lib/systemd/systemd-bootchart
to see the never ending loop.
This patch uses access("/proc/vmstat", F_OK) to detect procfs.
---
man/systemd-bootchart.xml | 4 +++-
src/bootchart/bootchart.c | 11 +++
src/bootchart/store.c | 29 -
3 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/man/systemd-bootchart.xml b/man/systemd-bootchart.xml
index e19bbc1..150ca48 100644
--- a/man/systemd-bootchart.xml
+++ b/man/systemd-bootchart.xml
@@ -131,7 +131,9 @@
not graph the time elapsed since boot
and before systemd-bootchart was
started, as it may result in extremely
-large graphs.
+large graphs. The time elapsed since boot
+might also include any time that the system
+was suspended.
diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c
index cbfc28d..909ef46 100644
--- a/src/bootchart/bootchart.c
+++ b/src/bootchart/bootchart.c
@@ -310,6 +310,7 @@ int main(int argc, char *argv[]) {
time_t t = 0;
int r;
struct rlimit rlim;
+bool has_procfs = false;
parse_conf();
@@ -349,6 +350,8 @@ int main(int argc, char *argv[]) {
log_uptime();
+has_procfs = access("/proc/vmstat", F_OK) == 0;
+
LIST_HEAD_INIT(head);
/* main program loop */
@@ -385,11 +388,11 @@ int main(int argc, char *argv[]) {
parse_env_file("/usr/lib/os-release", NEWLINE,
"PRETTY_NAME", &build, NULL);
}
-/* wait for /proc to become available, discarding samples */
-if (graph_start <= 0.0)
-log_uptime();
-else
+if (has_procfs)
log_sample(samples, &sampledata);
+else
+/* wait for /proc to become available, discarding
samples */
+has_procfs = access("/proc/vmstat", F_OK) == 0;
sample_stop = gettime_ns();
diff --git a/src/bootchart/store.c b/src/bootchart/store.c
index e071983..cedcba8 100644
--- a/src/bootchart/store.c
+++ b/src/bootchart/store.c
@@ -57,27 +57,22 @@ double gettime_ns(void) {
return (n.tv_sec + (n.tv_nsec / 10.0));
}
-void log_uptime(void) {
-_cleanup_fclose_ FILE *f = NULL;
-char str[32];
-double uptime;
-
-f = fopen("/proc/uptime", "re");
-
-if (!f)
-return;
-if (!fscanf(f, "%s %*s", str))
-return;
-
-uptime = strtod(str, NULL);
+static double gettime_up(void) {
+struct timespec n;
-log_start = gettime_ns();
+clock_gettime(CLOCK_BOOTTIME, &n);
+return (n.tv_sec + (n.tv_nsec / 10.0));
+}
-/* start graph at kernel boot time */
+void log_uptime(void) {
if (arg_relative)
-graph_start = log_start;
-else
+graph_start = log_start = gettime_ns();
+else {
+double uptime = gettime_up();
+
+log_start = gettime_ns();
graph_start = log_start - uptime;
+}
}
static char *bufgetline(char *buf) {
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] bootchart: ask for --rel when failed to initialize graph start time
We always read system uptime before log start time. So the uptime
should be always smaller number, except it includes system suspend
time. It seems better to ask for --rel and exit() than try to be
smart and try to recovery from this situation or generate huge
messy graphs.
---
src/bootchart/bootchart.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c
index 909ef46..22c66ba 100644
--- a/src/bootchart/bootchart.c
+++ b/src/bootchart/bootchart.c
@@ -350,6 +350,14 @@ int main(int argc, char *argv[]) {
log_uptime();
+if (graph_start < 0.0) {
+fprintf(stderr,
+"Failed to setup graph start time.\n\nThe system
uptime "
+"probably includes time that the system was suspended.
"
+"Use --rel to bypass this issue.\n");
+exit (EXIT_FAILURE);
+}
+
has_procfs = access("/proc/vmstat", F_OK) == 0;
LIST_HEAD_INIT(head);
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: only execute chmod()/chown() when needed
On Fri, Jul 11, 2014 at 03:05:05PM +0200, Michael Olbrich wrote:
> This avoids errors like this, when the paths are already there with the
> correct permissions and owner:
>
> chmod(/var/spool) failed: Read-only file system
Ping. These warnings are rather annoying and they make it hard to find
those that are actually a problem :-/.
Michael
> ---
> src/tmpfiles/tmpfiles.c | 36 +---
> 1 file changed, 21 insertions(+), 15 deletions(-)
>
> diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
> index 68cfa55..4f41f28 100644
> --- a/src/tmpfiles/tmpfiles.c
> +++ b/src/tmpfiles/tmpfiles.c
> @@ -453,35 +453,41 @@ finish:
> }
>
> static int item_set_perms(Item *i, const char *path) {
> +struct stat st;
> +mode_t old_m = ~0;
> +uid_t old_uid = -1;
> +gid_t old_gid = -1;
> +
> assert(i);
> assert(path);
>
> +if (stat(path, &st) >= 0) {
> +old_m = st.st_mode & 0;
> +old_uid = st.st_uid;
> +old_gid = st.st_gid;
> +}
> /* not using i->path directly because it may be a glob */
> if (i->mode_set) {
> mode_t m = i->mode;
>
> -if (i->mask_perms) {
> -struct stat st;
> -
> -if (stat(path, &st) >= 0) {
> -if (!(st.st_mode & 0111))
> -m &= ~0111;
> -if (!(st.st_mode & 0222))
> -m &= ~0222;
> -if (!(st.st_mode & 0444))
> -m &= ~0444;
> -if (!S_ISDIR(st.st_mode))
> -m &= ~07000; /* remove
> sticky/sgid/suid bit, unless directory */
> -}
> +if (i->mask_perms && old_m != ~0) {
> +if (!(st.st_mode & 0111))
> +m &= ~0111;
> +if (!(st.st_mode & 0222))
> +m &= ~0222;
> +if (!(st.st_mode & 0444))
> +m &= ~0444;
> +if (!S_ISDIR(st.st_mode))
> +m &= ~07000; /* remove sticky/sgid/suid bit,
> unless directory */
> }
>
> -if (chmod(path, m) < 0) {
> +if (m != old_m && chmod(path, m) < 0) {
> log_error("chmod(%s) failed: %m", path);
> return -errno;
> }
> }
>
> -if (i->uid_set || i->gid_set)
> +if ((i->uid_set || i->gid_set) && (i->uid != old_uid || i->gid !=
> old_gid))
> if (chown(path,
>i->uid_set ? i->uid : (uid_t) -1,
>i->gid_set ? i->gid : (gid_t) -1) < 0) {
> --
> 2.0.1
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
