[systemd-devel] [PATCH] journalctl: make --utc work everywhere
The --utc option was introduced by commit
9fd290443f5f99fca0dcd4216b1de70f7d3b8db1.
Howerver, the implementation was incomplete.
---
src/journal/journalctl.c | 14 +++---
src/shared/logs-show.c | 2 +-
src/shared/time-util.c | 19 +++
src/shared/time-util.h | 3 ++-
4 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 395f85c..816934e 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -890,8 +890,8 @@ static int list_boots(sd_journal *j) {
printf(% *i SD_ID128_FORMAT_STR %s—%s\n,
w, i - count + 1,
SD_ID128_FORMAT_VAL(id-id),
- format_timestamp(a, sizeof(a), id-first),
- format_timestamp(b, sizeof(b), id-last));
+ format_timestamp_internal(a, sizeof(a), id-first,
arg_utc),
+ format_timestamp_internal(b, sizeof(b), id-last,
arg_utc));
}
return 0;
@@ -1502,8 +1502,8 @@ static int verify(sd_journal *j) {
if (arg_verify_key
JOURNAL_HEADER_SEALED(f-header)) {
if (validated 0) {
log_info(= Validated from %s to %s,
final %s entries not sealed.,
- format_timestamp(a,
sizeof(a), first),
- format_timestamp(b,
sizeof(b), validated),
+ format_timestamp_internal(a,
sizeof(a), first, arg_utc),
+ format_timestamp_internal(b,
sizeof(b), validated, arg_utc),
format_timespan(c, sizeof(c),
last validated ? last - validated : 0, 0));
} else if (last 0)
log_info(= No sealing yet, %s of
entries not sealed.,
@@ -1898,11 +1898,11 @@ int main(int argc, char *argv[]) {
if (r 0) {
if (arg_follow)
printf(-- Logs begin at %s. --\n,
- format_timestamp(start_buf,
sizeof(start_buf), start));
+ format_timestamp_internal(start_buf,
sizeof(start_buf), start, arg_utc));
else
printf(-- Logs begin at %s, end at %s. --\n,
- format_timestamp(start_buf,
sizeof(start_buf), start),
- format_timestamp(end_buf,
sizeof(end_buf), end));
+ format_timestamp_internal(start_buf,
sizeof(start_buf), start, arg_utc),
+ format_timestamp_internal(end_buf,
sizeof(end_buf), end, arg_utc));
}
}
diff --git a/src/shared/logs-show.c b/src/shared/logs-show.c
index d5d9d09..e30e686 100644
--- a/src/shared/logs-show.c
+++ b/src/shared/logs-show.c
@@ -447,7 +447,7 @@ static int output_verbose(
}
fprintf(f, %s [%s]\n,
-format_timestamp_us(ts, sizeof(ts), realtime),
+format_timestamp_us(ts, sizeof(ts), realtime, flags
OUTPUT_UTC),
cursor);
JOURNAL_FOREACH_DATA_RETVAL(j, data, length, r) {
diff --git a/src/shared/time-util.c b/src/shared/time-util.c
index 066ef97..09f4a21 100644
--- a/src/shared/time-util.c
+++ b/src/shared/time-util.c
@@ -152,7 +152,7 @@ struct timeval *timeval_store(struct timeval *tv, usec_t u)
{
return tv;
}
-char *format_timestamp(char *buf, size_t l, usec_t t) {
+char *format_timestamp_internal(char *buf, size_t l, usec_t t, bool utc) {
struct tm tm;
time_t sec;
@@ -164,13 +164,21 @@ char *format_timestamp(char *buf, size_t l, usec_t t) {
sec = (time_t) (t / USEC_PER_SEC);
-if (strftime(buf, l, %a %Y-%m-%d %H:%M:%S %Z, localtime_r(sec,
tm)) = 0)
+if (utc)
+gmtime_r(sec, tm);
+else
+localtime_r(sec, tm);
+if (strftime(buf, l, %a %Y-%m-%d %H:%M:%S %Z, tm) = 0)
return NULL;
return buf;
}
-char *format_timestamp_us(char *buf, size_t l, usec_t t) {
+char *format_timestamp(char *buf, size_t l, usec_t t) {
+return format_timestamp_internal(buf, l, t, false);
+}
+
+char *format_timestamp_us(char *buf, size_t l, usec_t t, bool utc) {
struct tm tm;
time_t sec;
@@ -181,7 +189,10 @@ char *format_timestamp_us(char *buf, size_t l, usec_t t) {
return NULL;
sec = (time_t) (t / USEC_PER_SEC);
-localtime_r(sec, tm);
+if (utc)
+gmtime_r(sec, tm);
+else
+localtime_r(sec, tm);
if (strftime(buf, l, %a %Y-%m-%d %H:%M:%S, tm) = 0)
Re: [systemd-devel] [question] networkd: Any support for hooks?
Op 2 okt. 2014, om 15:29 heeft Tom Gundersen t...@jklm.no het volgende geschreven: On Thu, Oct 2, 2014 at 2:20 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 02.10.14 13:00, Koen Kooi (k...@dominion.thruhere.net) wrote: Op 2 okt. 2014, om 07:36 heeft Tom Gundersen t...@jklm.no het volgende geschreven: Hi Cameron, On Thu, Oct 2, 2014 at 6:36 AM, Cameron Norman camerontnor...@gmail.com wrote: ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). For specific hooks, we may want to integrate them directly upstream, but it really depends on what functionality you have in mind. For my use-case (fiber 'modem' doing PPPoE over vlan) I'd like to launch accelpppd to do PPPoE as soon as the vlan is up. That get me my internet back a few ms earlier when rebooting the modem :) Hmm, Tom has some patches adding native pppoe support to networkd (without pppd), iirc. Might be a better option to finish those. Tom? Yes, I have some WIP patches to do PPPoE directly from networkd [0]. If you are interested in using this, I'll clean it up and get it ready for merging/testing. I'm certainly interested, but I can't promise to test it in a timely fashion since it needs to run on my fiber modem. regards, Koen Cheers, Tom [0]: http://cgit.freedesktop.org/~tomegun/systemd/log/?h=ppp ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v1 5/5] driver-core: add driver asynchronous probe support
On Thu, Oct 2, 2014 at 10:06 PM, Luis R. Rodriguez mcg...@suse.com wrote: On Thu, Oct 02, 2014 at 08:12:37AM +0200, Tom Gundersen wrote: Making kmod a special case is of course possible. However, as long as there is no fundamental reason why kmod should get this special treatment, this just looks like a work-around to me. I've mentioned a series of five reasons why its a bad idea right now to sigkill modules [0], we're reviewed them each and still at least items 2-4 remain particularly valid fundamental reasons to avoid it So items 2-4 basically say there currently are drivers that cannot deal with sigkill after a three minute timeout. In the short-term we already have the solution: increase the timeout. In the long-term, we have two choices, either permanently add some heuristic to udev to deal with drivers taking a very long time to be inserted, or fix the drivers not to take such a long time. A priori, it makes no sense to me that drivers spend unbounded amounts of time to get inserted, so fixing the drivers seems like the most reasonable approach to me. That said, I'm of course open to be proven wrong if there are some drivers that fundamentally _must_ take a long time to insert (but we should then discuss why that is and how we can best deal with the situation, rather than adding some hack up-front when we don't even know if it is needed). Your patch series should go a long way towards fixing the drivers (and I imagine there being a lot of low-hanging fruit that can easily be fixed once your series has landed), and the fact that we have now increased the udev timeout from 30 to 180 seconds should also greatly reduce the problem. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] localectl: print warning when there are options given on kernel cmdline
On Thu, Oct 02, 2014 at 02:39:10PM +0200, Lennart Poettering wrote:
On Wed, 24.09.14 17:18, Michal Sekletar (msekl...@redhat.com) wrote:
Heya,
+for (j = VARIABLE_LANG; j _VARIABLE_LC_MAX; j++)
I think it is much nicer to count from an explicit 0 on here,
instead of VARIABLE_LANG, since this makes the loop work correctly
even if the order of the enum is changed.
+if (variables[j]) {
+if (print_warning) {
+printf(Warning: Settings on Kernel
Command Line override system locale settings in /etc/locale.conf\n);
+printf(Command Line: %s=%s\n,
locale_variable_to_string(j), variables[j]);
Warnings should be printed with log_warning() and not printf() so that they
end up on stderr, not stdout.
I fixed this now in git.
Thanks, for clean-ups. Much appreciated.
Michal
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] [uml-devel] Timed out waiting for device dev-disk-by...
Zitat von Lennart Poettering lenn...@poettering.net: On Tue, 30.09.14 21:44, Tomasz Torcz (to...@pipebreaker.pl) wrote: Check the udev database at this moment. In my understanding, to have device deemed ready by systemd, two things must happen for device entry: – TAGS variable must contain ”systemd” – SYSTEMD_READY must be ”1” Well, the latter is not entirely correct. It's reversed: the SYSTEMD_READY field must not be 0. Or in other words, either be 1 or absent, for systemd to consider the device around. I'd really like to the the udev info output for the actual device missing here, rather than an unrelated one. Hi, I think the confusion with the device id comes from that fact that I posted the results from two different boots: 1.) Trying to boot from the Fedora 21-Alpha with the contained initrd image - waits forever for /dev/ubdb1 resp. /dev/ubdb3, which are the partitions on the ISO image 2.) Boot from a Fedora 21 alpha installation, which waits forever for device with UUID 008af19d-2562-49bd-8907-721ea08f3e14, which is /dev/ubda1, which contains the /boot partition the error happens in both situations, so I thought I shouldn't matter which one to post. anyway, here is the info you asked for: # systemctl status dev-disk-by\x2duuid-008af19d\x2d2562\x2d49bd\x2d8907\x2d721ea08f3e14.device ● dev-disk-byx2duuid-008af19dx2d2562x2d49bdx2d8907x2d721ea08f3e14.device Loaded: loaded Active: inactive (dead) # ls -ld /dev/disk/by-uuid/008af19d-2562-49bd-8907-721ea08f3e14 lrwxrwxrwx 1 root root 11 Oct 3 13:15 /dev/disk/by-uuid/008af19d-2562-49bd-8907-721ea08f3e14 - ../../ubda1 # udevadm info -q path -n /dev/ubda1 /devices/platform/uml-blkdev.0/block/ubda/ubda1 # udevadm info -q all -p /devices/platform/uml-blkdev.0/block/ubda/ubda1 P: /devices/platform/uml-blkdev.0/block/ubda/ubda1 N: ubda1 S: disk/by-path/platform-uml-blkdev.0-part1 S: disk/by-uuid/008af19d-2562-49bd-8907-721ea08f3e14 E: DEVLINKS=/dev/disk/by-path/platform-uml-blkdev.0-part1 /dev/disk/by-uuid/008af19d-2562-49bd-8907-721ea08f3e14 E: DEVNAME=/dev/ubda1 E: DEVPATH=/devices/platform/uml-blkdev.0/block/ubda/ubda1 E: DEVTYPE=partition E: ID_FS_TYPE=ext4 E: ID_FS_USAGE=filesystem E: ID_FS_UUID=008af19d-2562-49bd-8907-721ea08f3e14 E: ID_FS_UUID_ENC=008af19d-2562-49bd-8907-721ea08f3e14 E: ID_FS_VERSION=1.0 E: ID_PART_ENTRY_DISK=98:0 E: ID_PART_ENTRY_FLAGS=0x80 E: ID_PART_ENTRY_NUMBER=1 E: ID_PART_ENTRY_OFFSET=2048 E: ID_PART_ENTRY_SCHEME=dos E: ID_PART_ENTRY_SIZE=1024000 E: ID_PART_ENTRY_TYPE=0x83 E: ID_PART_ENTRY_UUID=73764b38-01 E: ID_PART_TABLE_TYPE=dos E: ID_PART_TABLE_UUID=73764b38 E: ID_PATH=platform-uml-blkdev.0 E: ID_PATH_TAG=platform-uml-blkdev_0 E: MAJOR=98 E: MINOR=1 E: SUBSYSTEM=block E: TAGS=:systemd: E: USEC_INITIALIZED=50322 # cat /etc/fstab # # /etc/fstab # Created by anaconda on Sun Sep 28 14:27:03 2014 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # UUID=e2bffa45-d84f-47bc-81ba-e7a395751fa6 / ext4 defaults1 1 UUID=008af19d-2562-49bd-8907-721ea08f3e14 /boot ext4 defaults1 2 UUID=f452f020-a446-41ed-93c0-ee5ce56d6ea4 swapswap defaults0 0 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
Re: [systemd-devel] [PATCH] sd-dhcp-client: support non-Ethernet hardware addresses
Hi, On Thu, 2014-10-02 at 20:05 +0200, Tom Gundersen wrote: The DHCPv4 header is the same format no matter what the LL address size, but for non-ethernet the hlen is 0 and the chaddr is zeroed. The BPF is seeded with an hlen of 0 and a valid ETH_ALEN sized buffer of all zeros. So both the hlen and chaddr comparisons comparison should succeed. Does that make sense? I might have missed something too though... So that sounds fine, but my concern was: are we guaranteed that all implementations properly zero out the remaining bytes past the hlen first ones? Sounds weird to reject a package if it has hlen == 0 and garbage in chaddr, or is the zeroing something we can rely on? (In that case I guess we should extend the check to check all 16 bytes, and not only the 6 first ones to make it truly agnostic). Patrik, any thoughts? At least RFC2131 says that the DHCP server uses the 'chaddr' supplied by the client without considering hardware address length in 'hlen'. Apparently both client and server need to use the same hardware addressing, so 'hlen' on both ends match anyway. Since our client implementation has properly zeroed out the DHCP header before filling it with information, there should be no problem just comparing all 16 bytes of 'chaddr' where the first 'hlen' bytes is the hardware address and the rest should definitely be zero, since that was what was sent in the first place. Currently the client side implementation only checks that the N first bytes containing the MAC address, so technically that is a bug. For a hardware address length of zero, 'chaddr' should match what the client sent, in our case 16 bytes of zeroes. Cheers, Patrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: make --utc work everywhere
On Fri, Oct 03, 2014 at 09:51:33AM +0200, Jan Synacek wrote: The --utc option was introduced by commit 9fd290443f5f99fca0dcd4216b1de70f7d3b8db1. Howerver, the implementation was incomplete. --- src/journal/journalctl.c | 14 +++--- src/shared/logs-show.c | 2 +- src/shared/time-util.c | 19 +++ src/shared/time-util.h | 3 ++- 4 files changed, 25 insertions(+), 13 deletions(-) Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3] bootchart: use 'n/a' if PRETTY_NAME is not found
On Fri, Sep 26, 2014 at 10:01:32PM +0200, Thomas H.P. Andersen wrote:
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com
Spotted with coverity. If parsing both /etc/os-release and
/usr/lib/os-release fails then null would be passed on. The calls
to parse the two files are allowed to fail. A empty /etc may not
have had the /etc/os-release symlink restored yet and we just
try again in the loop. If for whatever reason that does not happen
then we now pass on 'n/a' instead of null.
---
src/bootchart/bootchart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c
index e127ad3..a359307 100644
--- a/src/bootchart/bootchart.c
+++ b/src/bootchart/bootchart.c
@@ -477,7 +477,7 @@ int main(int argc, char *argv[]) {
exit (EXIT_FAILURE);
}
-svg_do(build);
+svg_do(strna(build));
I think think one is valid, but got forgotten. Applied now.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: support non-Ethernet hardware addresses
On Fri, 2014-10-03 at 15:48 +0300, Patrik Flykt wrote: On Fri, 2014-09-26 at 15:15 -0500, Dan Williams wrote: /* RFC2132 section 4.1.1: The client MUST include its hardware address in the ’chaddr’ field, if - necessary for delivery of DHCP reply messages. + necessary for delivery of DHCP reply messages. Non-Ethernet + interfaces will leave 'chaddr' empty and use the client identifier + instead (eg, RFC 4390 section 2.1). */ -memcpy(packet-dhcp.chaddr, client-client_id.mac_addr, ETH_ALEN); +if (client-mac_addr_len == ETH_ALEN) +memcpy(packet-dhcp.chaddr, client-mac_addr, ETH_ALEN); Sorry about the late review, but shouldn't this be more generic if written: if (client-mac_addr_len) memcpy(packet-dhcp.chaddr, client-mac_addr, client-mac_addr_len); With that, all cases are covered. Which, AFAIK, are none in addition to ethernet. An assert() should check the given MAC address length at some point in the code so that it cannot be 16. And then I notice that infiniband has a MAC address length of 20. For all practical purposes this works as expected. Except if we want to go nitpicking when setting the MAC address and also require the address type to be supplied? Probably not... Cheers, Patrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] ask-password: Add --echo to enable echoing the user input
Programs such as OpenVPN may use ask-password for not only retrieving
passwords, but also usernames. Masking usernames with * seems just silly.
v2 - Don't mess with termios flags, instead print the input
instead of an asterix. Resolves issues with backspace
and TAB input.
v3 - Renamed 'do_echo' variables and argument to 'echo'. Also
modified the ask_password_{tty,agent,auto} API instead of
additional wrapper functions.
---
man/systemd-ask-password.xml| 9 +
src/ask-password/ask-password.c | 12 ++--
src/cryptsetup/cryptsetup.c | 4 ++--
src/firstboot/firstboot.c | 4 ++--
src/shared/ask-password-api.c | 12
src/shared/ask-password-api.h | 6 +++---
src/tty-ask-password-agent/tty-ask-password-agent.c | 5 +++--
7 files changed, 37 insertions(+), 15 deletions(-)
diff --git a/man/systemd-ask-password.xml b/man/systemd-ask-password.xml
index ce0ac3d..bfe646f 100644
--- a/man/systemd-ask-password.xml
+++ b/man/systemd-ask-password.xml
@@ -127,6 +127,15 @@
/varlistentry
varlistentry
+termoption--echo/option/term
+
+listitemparaEcho the user input
+instead of masking it. This is useful
+when using systemd-ask-password to
+query for usernames./para/listitem
+/varlistentry
+
+varlistentry
termoption--no-tty/option/term
listitemparaNever ask for password
diff --git a/src/ask-password/ask-password.c b/src/ask-password/ask-password.c
index 5c37cff..54acace 100644
--- a/src/ask-password/ask-password.c
+++ b/src/ask-password/ask-password.c
@@ -45,6 +45,7 @@
static const char *arg_icon = NULL;
static const char *arg_id = NULL;
static const char *arg_message = NULL;
+static bool arg_echo = false;
static bool arg_use_tty = true;
static usec_t arg_timeout = DEFAULT_TIMEOUT_USEC;
static bool arg_accept_cached = false;
@@ -56,6 +57,7 @@ static void help(void) {
-h --help Show this help\n
--icon=NAME Icon name\n
--timeout=SEC Timeout in sec\n
+--echo Do not mask the user input. Used when
asking for usernames\n
--no-ttyAsk question via agent even on TTY\n
--accept-cached Accept cached passwords\n
--multiple List multiple passwords if available\n
@@ -68,6 +70,7 @@ static int parse_argv(int argc, char *argv[]) {
enum {
ARG_ICON = 0x100,
ARG_TIMEOUT,
+ARG_ECHO,
ARG_NO_TTY,
ARG_ACCEPT_CACHED,
ARG_MULTIPLE,
@@ -78,6 +81,7 @@ static int parse_argv(int argc, char *argv[]) {
{ help, no_argument, NULL, 'h'
},
{ icon, required_argument, NULL, ARG_ICON
},
{ timeout, required_argument, NULL, ARG_TIMEOUT
},
+{ echo, no_argument, NULL, ARG_ECHO
},
{ no-tty,no_argument, NULL, ARG_NO_TTY
},
{ accept-cached, no_argument, NULL, ARG_ACCEPT_CACHED
},
{ multiple, no_argument, NULL, ARG_MULTIPLE
},
@@ -109,6 +113,10 @@ static int parse_argv(int argc, char *argv[]) {
}
break;
+case ARG_ECHO:
+arg_echo = true;
+break;
+
case ARG_NO_TTY:
arg_use_tty = false;
break;
@@ -160,7 +168,7 @@ int main(int argc, char *argv[]) {
if (arg_use_tty isatty(STDIN_FILENO)) {
char *password = NULL;
-if ((r = ask_password_tty(arg_message, timeout, NULL,
password)) = 0) {
+if ((r = ask_password_tty(arg_message, timeout, arg_echo,
NULL, password)) = 0) {
puts(password);
free(password);
}
@@ -168,7 +176,7 @@ int main(int argc, char *argv[]) {
} else {
char **l;
-if ((r = ask_password_agent(arg_message, arg_icon, arg_id,
timeout, arg_accept_cached, l)) = 0) {
+if ((r = ask_password_agent(arg_message, arg_icon, arg_id,
timeout, arg_echo, arg_accept_cached, l)) = 0) {
char **p;
STRV_FOREACH(p, l) {
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index 94570eb..ed4866e
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
On Thu, Oct 2, 2014 at 3:15 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 24.09.14 22:08, Tobias Hunger (tobias.hun...@gmail.com) wrote:
The patch is line-broken, please resend non-linebroken version!
I'll fix that, sorry.
+static int add_usr_mount(void) {
+_cleanup_free_ char *what = NULL;
+const char *opts;
+
+if (!arg_usr_what !arg_usr_fstype !arg_usr_options)
+return 0;
+
+if (arg_root_what !arg_usr_what)
+arg_usr_what = strdup(arg_root_what);
Hmm, what's the rationale here? I mean, then we'd mount the same stuff
to /usr that we already mount to / if one field is missing, is that
really disarable? Maybe better do a warning instead?
This patch should make it easy to mount the root:something and
usr:something subvolumes you had proposed earlier. / and /usr both
are separate in that proposal, but expected to be subvolumes of the
same BTRFS partition. So to keep the kernel commandline short, I just
went ahead and copied the missing arg_usr_* from the corresponding
arg_root_*.
Usually arg_usr_what and arg_usr_fstype will be unset and only
arg_usr_options will point to the usr:whatever subvolume on the same
BTRFS partition that is also used for /.
I see no reason not enforce this by removing the other options, though.
snip
Otherwise looks good to me, but I'd really like Harald Hoyer's
feedback on this, before we merge this.
Great:-) My C-foo is seriously rusted.
I am not entirely sure what our strategy here is precisely, and I think
dracut might already have something here.
I did not see anything, but having something in systemd would be nice
for distros not using dracut -- like the archlinux I am on.
Best Regards,
Tobias
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
From 681971f9cca5b3db085f47750f27f3f8d51f5036 Mon Sep 17 00:00:00 2001 From: Tobias Hunger tobias.hun...@digia.com Date: Wed, 24 Sep 2014 21:57:00 +0200 Subject: [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags= on kernel command line This allows to configure boot loader entries for systems where the root and usr filesystems are in different subvolumes (or even on different drives). --- man/systemd-fstab-generator.xml | 76 - src/fstab-generator/fstab-generator.c | 90 +-- 2 files changed, 160 insertions(+), 6 deletions(-) diff --git a/man/systemd-fstab-generator.xml b/man/systemd-fstab-generator.xml index e3cf5d2..63a3db5 100644 --- a/man/systemd-fstab-generator.xml +++ b/man/systemd-fstab-generator.xml @@ -104,9 +104,83 @@ (initrd) while varnamefstab=/varname is honored by both the main system and -the initrd. /para/listitem +the initrd./para/listitem /varlistentry +varlistentry +termvarnameroot=/varname/term + +listitemparaTakes the root filesystem to mount +in the initrd. +varnameroot=/varname is +honored by the initrd./para/listitem +/varlistentry +varlistentry + termvarnamerootfstype=/varname/term + +listitemparaTakes the root filesystem type that +will be passed to the mount command. +varnamerootfstype=/varname is +honored by the initrd./para/listitem +/varlistentry +varlistentry + termvarnamerootflags=/varname/term + +listitemparaTakes the root filesystem mount options +to use. varnamerootflags=/varname is +honored by the initrd./para/listitem +/varlistentry +varlistentry +termvarnameusr=/varname/term + +listitemparaTakes the filename/usr/filename +filesystem to be mounted by the initrd. If +varnameusrfstype=/varname or +varnameusrflags=/varname is set, then +varnameusr=/varname will default to the value set in +varnameroot=/varname./para + +paraOtherwise this parameter defaults to the +filename/usr/filename entry +found in filename/etc/fstab/filename on the root +filesystem./para + +paravarnameusr=/varname is honored by the initrd. +/para/listitem +/varlistentry +varlistentry + termvarnameusrfstype=/varname/term + +listitemparaTakes the filename/usr/filename +filesystem type that will be passed to the mount +command. If varnameusr=/varname or +varnameusrflags=/varname is set, then +varnameusrfstype=/varname will default to the value set in +varnamerootfstype=/varname./para + +paraOtherwise this value will be read from the +filename/usr/filename entry in +filename/etc/fstab/filename on the root filesystem./para + +paravarnameusrfstype=/varname is +honored by the initrd./para/listitem +/varlistentry +varlistentry + termvarnameusrflags=/varname/term + +listitemparaTakes the filename/usr/filename +filesystem mount options to use. If +varnameusr=/varname or +varnameusrfstype=/varname is set, then +varnameusrflages=/varname will default to the value set in +varnamerootflags=/varname./para +paraOtherwise this value will be read from the +
[systemd-devel] [PATCH] Small cleanup for systemd-fstab-generator
From 4d038e78cd9656712a74901e0b6c79184764e7c1 Mon Sep 17 00:00:00 2001
From: Tobias Hunger tobias.hun...@digia.com
Date: Fri, 3 Oct 2014 16:29:30 +0200
Subject: [PATCH 1/2] fstab-generator: Small cleanup
---
src/fstab-generator/fstab-generator.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 5dafcba..b75bbb7 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -511,16 +511,12 @@ static int parse_proc_cmdline_item(const char
*key, const char *value) {
} else if (streq(key, root) value) {
-free(arg_root_what);
-arg_root_what = strdup(value);
-if (!arg_root_what)
+if (free_and_strdup(arg_root_what, value) 0)
return log_oom();
} else if (streq(key, rootfstype) value) {
-free(arg_root_fstype);
-arg_root_fstype = strdup(value);
-if (!arg_root_fstype)
+if (free_and_strdup(arg_root_fstype, value) 0)
return log_oom();
} else if (streq(key, rootflags) value) {
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: support non-Ethernet hardware addresses
On Fri, 2014-10-03 at 16:10 +0300, Patrik Flykt wrote: On Fri, 2014-10-03 at 15:48 +0300, Patrik Flykt wrote: On Fri, 2014-09-26 at 15:15 -0500, Dan Williams wrote: /* RFC2132 section 4.1.1: The client MUST include its hardware address in the ’chaddr’ field, if - necessary for delivery of DHCP reply messages. + necessary for delivery of DHCP reply messages. Non-Ethernet + interfaces will leave 'chaddr' empty and use the client identifier + instead (eg, RFC 4390 section 2.1). */ -memcpy(packet-dhcp.chaddr, client-client_id.mac_addr, ETH_ALEN); +if (client-mac_addr_len == ETH_ALEN) +memcpy(packet-dhcp.chaddr, client-mac_addr, ETH_ALEN); Sorry about the late review, but shouldn't this be more generic if written: if (client-mac_addr_len) memcpy(packet-dhcp.chaddr, client-mac_addr, client-mac_addr_len); With that, all cases are covered. Which, AFAIK, are none in addition to ethernet. An assert() should check the given MAC address length at some point in the code so that it cannot be 16. And then I notice that infiniband has a MAC address length of 20. For all practical purposes this works as expected. Except if we want to go nitpicking when setting the MAC address and also require the address type to be supplied? Probably not... sd_dhcp_client_set_mac() does have an 'arp_type' parameter that's cached in the client struct, so that could be changed to: if (client-arp_type == ARPHRD_ETHER) if you'd like. Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [uml-devel] Timed out waiting for device dev-disk-by...
В Fri, 03 Oct 2014 13:32:09 +0200 Thomas Meyer tho...@m3y3r.de пишет: Zitat von Lennart Poettering lenn...@poettering.net: On Tue, 30.09.14 21:44, Tomasz Torcz (to...@pipebreaker.pl) wrote: Check the udev database at this moment. In my understanding, to have device deemed ready by systemd, two things must happen for device entry: – TAGS variable must contain ”systemd” – SYSTEMD_READY must be ”1” Well, the latter is not entirely correct. It's reversed: the SYSTEMD_READY field must not be 0. Or in other words, either be 1 or absent, for systemd to consider the device around. I'd really like to the the udev info output for the actual device missing here, rather than an unrelated one. Hi, I think the confusion with the device id comes from that fact that I posted the results from two different boots: 1.) Trying to boot from the Fedora 21-Alpha with the contained initrd image - waits forever for /dev/ubdb1 resp. /dev/ubdb3, which are the partitions on the ISO image 2.) Boot from a Fedora 21 alpha installation, which waits forever for device with UUID 008af19d-2562-49bd-8907-721ea08f3e14, which is /dev/ubda1, which contains the /boot partition the error happens in both situations, so I thought I shouldn't matter which one to post. anyway, here is the info you asked for: # systemctl status dev-disk-by\x2duuid-008af19d\x2d2562\x2d49bd\x2d8907\x2d721ea08f3e14.device ● dev-disk-byx2duuid-008af19dx2d2562x2d49bdx2d8907x2d721ea08f3e14.device Loaded: loaded Active: inactive (dead) # ls -ld /dev/disk/by-uuid/008af19d-2562-49bd-8907-721ea08f3e14 lrwxrwxrwx 1 root root 11 Oct 3 13:15 /dev/disk/by-uuid/008af19d-2562-49bd-8907-721ea08f3e14 - ../../ubda1 # udevadm info -q path -n /dev/ubda1 /devices/platform/uml-blkdev.0/block/ubda/ubda1 # udevadm info -q all -p /devices/platform/uml-blkdev.0/block/ubda/ubda1 P: /devices/platform/uml-blkdev.0/block/ubda/ubda1 N: ubda1 S: disk/by-path/platform-uml-blkdev.0-part1 S: disk/by-uuid/008af19d-2562-49bd-8907-721ea08f3e14 E: DEVLINKS=/dev/disk/by-path/platform-uml-blkdev.0-part1 /dev/disk/by-uuid/008af19d-2562-49bd-8907-721ea08f3e14 E: DEVNAME=/dev/ubda1 E: DEVPATH=/devices/platform/uml-blkdev.0/block/ubda/ubda1 E: DEVTYPE=partition E: ID_FS_TYPE=ext4 E: ID_FS_USAGE=filesystem E: ID_FS_UUID=008af19d-2562-49bd-8907-721ea08f3e14 E: ID_FS_UUID_ENC=008af19d-2562-49bd-8907-721ea08f3e14 E: ID_FS_VERSION=1.0 E: ID_PART_ENTRY_DISK=98:0 E: ID_PART_ENTRY_FLAGS=0x80 E: ID_PART_ENTRY_NUMBER=1 E: ID_PART_ENTRY_OFFSET=2048 E: ID_PART_ENTRY_SCHEME=dos E: ID_PART_ENTRY_SIZE=1024000 E: ID_PART_ENTRY_TYPE=0x83 E: ID_PART_ENTRY_UUID=73764b38-01 E: ID_PART_TABLE_TYPE=dos E: ID_PART_TABLE_UUID=73764b38 E: ID_PATH=platform-uml-blkdev.0 E: ID_PATH_TAG=platform-uml-blkdev_0 E: MAJOR=98 E: MINOR=1 E: SUBSYSTEM=block E: TAGS=:systemd: E: USEC_INITIALIZED=50322 Hmm ... one of common reason for such problems recently was missing CONFIG_FHANDLE in kernel configuration. Could you verify that all required kernel options are set in your case? # cat /etc/fstab # # /etc/fstab # Created by anaconda on Sun Sep 28 14:27:03 2014 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # UUID=e2bffa45-d84f-47bc-81ba-e7a395751fa6 / ext4 defaults1 1 UUID=008af19d-2562-49bd-8907-721ea08f3e14 /boot ext4 defaults1 2 UUID=f452f020-a446-41ed-93c0-ee5ce56d6ea4 swapswap defaults0 0 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
Re: [systemd-devel] [PATCH v1 5/5] driver-core: add driver asynchronous probe support
On Fri, Oct 3, 2014 at 1:23 AM, Tom Gundersen t...@jklm.no wrote: On Thu, Oct 2, 2014 at 10:06 PM, Luis R. Rodriguez mcg...@suse.com wrote: On Thu, Oct 02, 2014 at 08:12:37AM +0200, Tom Gundersen wrote: Making kmod a special case is of course possible. However, as long as there is no fundamental reason why kmod should get this special treatment, this just looks like a work-around to me. I've mentioned a series of five reasons why its a bad idea right now to sigkill modules [0], we're reviewed them each and still at least items 2-4 remain particularly valid fundamental reasons to avoid it So items 2-4 basically say there currently are drivers that cannot deal with sigkill after a three minute timeout. No, dealing with the sigkill gracefully is all related to 2) as it says its probably a terrible idea to be triggering exit paths at random points on device drivers on init / probe. And while one could argue that perhaps that can be cleaned up I provided tons of references and even *research effort* on this particular area so the issues over this point should by no means easily be brushed off. And it may be true that we can fix some things on Linux but a) that requires a kernel upgrade on users and b) Some users may end up buying hardware that only is supported through a proprietary driver and getting those fixes is not trivial and almost impossible on some cases. 3) says it is fundamentally incorrect to limit with any arbitrary timeout the bus probe routine 4) talks about how the timeout is creating a limit on the number of devices a device driver can support on Linux as follows give the driver core batches *all* probes for one device driver serially: number_devices = systemd_timeout - max known probe time for driver We have device drivers which we *know* just on *probe* will take over 1 minute, this means that by default for these device drivers folks can only install 3 devices of that type on a system. One can surely address things on the kernel but again assuming folks use defaults and don't upgrade their kernel the sigkill is simply limiting Linux right now, even if it is for the short term. In the short-term we already have the solution: increase the timeout. Short term implicates what will be supported for a while for tons of deployments of systemd. The kernel command line work around for increasing the timeout is a reactive measure, its not addressing the problem architecturally. If the sigkill is going to be maintained for kmod its implications should be well documented as well in terms of the impact and limitations on both device drivers and number of devices a driver can support. In the long-term, we have two choices, either permanently add some heuristic to udev to deal with drivers taking a very long time to be inserted, or fix the drivers not to take such a long time. Drivers taking long on init should probably be addressed, drivers taking long on probe are not broken specially since the driver core probe's all supported devices on one device driver serially, so the probe time is actually cumulative. A priori, it makes no sense to me that drivers spend unbounded amounts of time to get inserted, so fixing the drivers seems like the most reasonable approach to me. That said, I'm of course open to be proven wrong if there are some drivers that fundamentally _must_ take a long time to insert (but we should then discuss why that is and how we can best deal with the situation, rather than adding some hack up-front when we don't even know if it is needed). Ok hold on. Async probe on the driver core will be a new feature and there are even caveats that Tejun pointed out which are important for distributions to consider before embracing it. Of course folks can ignore these but by no means should it be considered that tons of device device drivers were broken, what we are providing is a new mechanism. And then there are device drivers which will need work in order to use async probe, some will require fixes on init / probe assumptions as I provided for the amd64_edac driver but for others only time will tell what is required. Your patch series should go a long way towards fixing the drivers (and I imagine there being a lot of low-hanging fruit that can easily be fixed once your series has landed), and the fact that we have now increased the udev timeout from 30 to 180 seconds should also greatly reduce the problem. Sure, I do ask for folks to revisit the short term solution though, I did my best to communicate / document the issues. Luis ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [feature request] allow instances in file.preset
From Lennart Poettering, Thu 02 Oct 2014 at 17:42:36 (+0200) : Hence so far the idea was to look for the presets only in the dirs where we look for static data, but not for configuration. We can certainly revisit this though. This makes sense for system services, but for user services it is a bit strange that a user cannot modify its own preset files. I'll be happy to provide a patch, but I must test the behavior of systemd more carefully because user preset files in /etc/systemd/user-preset/*.preset does not seem to work in systemd master [but maybe my testing was too hasty, I'll keep you updated]. Thanks, Damien Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [uml-devel] Timed out waiting for device dev-disk-by...
Am 03.10.2014 um 17:51 schrieb Andrei Borzenkov arvidj...@gmail.com: В Fri, 03 Oct 2014 13:32:09 +0200 Thomas Meyer tho...@m3y3r.de пишет: Zitat von Lennart Poettering lenn...@poettering.net: On Tue, 30.09.14 21:44, Tomasz Torcz (to...@pipebreaker.pl) wrote: Check the udev database at this moment. In my understanding, to have device deemed ready by systemd, two things must happen for device entry: – TAGS variable must contain ”systemd” – SYSTEMD_READY must be ”1” Well, the latter is not entirely correct. It's reversed: the SYSTEMD_READY field must not be 0. Or in other words, either be 1 or absent, for systemd to consider the device around. I'd really like to the the udev info output for the actual device missing here, rather than an unrelated one. Hi, I think the confusion with the device id comes from that fact that I posted the results from two different boots: 1.) Trying to boot from the Fedora 21-Alpha with the contained initrd image - waits forever for /dev/ubdb1 resp. /dev/ubdb3, which are the partitions on the ISO image 2.) Boot from a Fedora 21 alpha installation, which waits forever for device with UUID 008af19d-2562-49bd-8907-721ea08f3e14, which is /dev/ubda1, which contains the /boot partition the error happens in both situations, so I thought I shouldn't matter which one to post. anyway, here is the info you asked for: # systemctl status dev-disk-by\x2duuid-008af19d\x2d2562\x2d49bd\x2d8907\x2d721ea08f3e14.device ● dev-disk-byx2duuid-008af19dx2d2562x2d49bdx2d8907x2d721ea08f3e14.device Loaded: loaded Active: inactive (dead) # ls -ld /dev/disk/by-uuid/008af19d-2562-49bd-8907-721ea08f3e14 lrwxrwxrwx 1 root root 11 Oct 3 13:15 /dev/disk/by-uuid/008af19d-2562-49bd-8907-721ea08f3e14 - ../../ubda1 # udevadm info -q path -n /dev/ubda1 /devices/platform/uml-blkdev.0/block/ubda/ubda1 # udevadm info -q all -p /devices/platform/uml-blkdev.0/block/ubda/ubda1 P: /devices/platform/uml-blkdev.0/block/ubda/ubda1 N: ubda1 S: disk/by-path/platform-uml-blkdev.0-part1 S: disk/by-uuid/008af19d-2562-49bd-8907-721ea08f3e14 E: DEVLINKS=/dev/disk/by-path/platform-uml-blkdev.0-part1 /dev/disk/by-uuid/008af19d-2562-49bd-8907-721ea08f3e14 E: DEVNAME=/dev/ubda1 E: DEVPATH=/devices/platform/uml-blkdev.0/block/ubda/ubda1 E: DEVTYPE=partition E: ID_FS_TYPE=ext4 E: ID_FS_USAGE=filesystem E: ID_FS_UUID=008af19d-2562-49bd-8907-721ea08f3e14 E: ID_FS_UUID_ENC=008af19d-2562-49bd-8907-721ea08f3e14 E: ID_FS_VERSION=1.0 E: ID_PART_ENTRY_DISK=98:0 E: ID_PART_ENTRY_FLAGS=0x80 E: ID_PART_ENTRY_NUMBER=1 E: ID_PART_ENTRY_OFFSET=2048 E: ID_PART_ENTRY_SCHEME=dos E: ID_PART_ENTRY_SIZE=1024000 E: ID_PART_ENTRY_TYPE=0x83 E: ID_PART_ENTRY_UUID=73764b38-01 E: ID_PART_TABLE_TYPE=dos E: ID_PART_TABLE_UUID=73764b38 E: ID_PATH=platform-uml-blkdev.0 E: ID_PATH_TAG=platform-uml-blkdev_0 E: MAJOR=98 E: MINOR=1 E: SUBSYSTEM=block E: TAGS=:systemd: E: USEC_INITIALIZED=50322 Hmm ... one of common reason for such problems recently was missing CONFIG_FHANDLE in kernel configuration. Could you verify that all required kernel options are set in your case? Hi Andrei, Thanks for this tip! My kernel config did indeed miss the CONFIG_FHANDLE option. After recompiling the kernel, the devices where automatically detected by systemd! Does systemd log a message somewhere about this missing kernel option? Did I miss the relevant notice in the log messages? Anyway thanks for you help. # cat /etc/fstab # # /etc/fstab # Created by anaconda on Sun Sep 28 14:27:03 2014 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # UUID=e2bffa45-d84f-47bc-81ba-e7a395751fa6 / ext4 defaults1 1 UUID=008af19d-2562-49bd-8907-721ea08f3e14 /boot ext4 defaults1 2 UUID=f452f020-a446-41ed-93c0-ee5ce56d6ea4 swapswap defaults0 0 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
Re: [systemd-devel] [feature request] allow instances in file.preset
From Lennart Poettering, Thu 02 Oct 2014 at 17:32:07 (+0200) : Would it be possible for the .preset file to just specify foo@.service and then the code that actually enables it just process the DefaultInstance rule as normal? That should already work, no? Yes it works: in 90-systemd.preset, the line enable getty@.service correctly enables getty@tty1.service -- Damien Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [feature request] allow instances in file.preset
From Lennart Poettering, Thu 02 Oct 2014 at 16:48:19 (+0200) : Well, but from somewhere systemctl preset-all needs to be able to discover the bar string... How is that supposed to work? preset-all just enumerates all unit files that are installed and enables/disables them according to the preset file. But this means it would only find the template, and the instance would have to come from somewhere else, but where? From the preset file? I agree that since the enable/disable directive denotes glob, they are not well suited for instances services. Maybe add a new directive: instanciate foo@bar.service uninstanciate foo@bar.service (the uninstanciate is because disable does not disable instancied service for the same reason enable doe not enable them). I do not feel too strongly on this feature, afterwards it might as well be easier to call systemctl enable directly... Thanks, Damien Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd-nspawn: Cannot create tun device in container
Hello, list! In some work I've been doing with systemd-nspawn containers, I've been trying to connect one of my containers to an openvpn network. This conteiner is being run with the --network-bridge flag to setup its networking, so according to the documentation, should retain CAP_NET_ADMIN capabilities. However, the container appears to be unable to create a new tun device [root@lanvpn ~]# ip tuntap add dev tun0 mode tun open: No such file or directory I tried retaining the CAP_MKNOD capability for this container using the -- capability flag as well, and this met with the same result. I also tried binding the /dev/net device directory from the parent to the /dev/net device directory of the child container, and added the following line to the systemd-nspawn service file of the container [root@host01 ~]# grep Device /etc/systemd/system/lanvpn.service DeviceAllow=/dev/net/tun rwm This resulted in the error [root@lanvpn ~]# ip tuntap add tun0 mode tun open: Operation not permitted Is there any way to run my containers which will allow them to create tun/tap devices? System is arch linux arm, running systemd 216-r3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [feature request] allow instances in file.preset
From Damien Robert, Fri 03 Oct 2014 at 19:18:31 (+0200) : From the preset file? I agree that since the enable/disable directive denotes glob, they are not well suited for instances services. Maybe add a new directive: instanciate foo@bar.service uninstanciate foo@bar.service (the uninstanciate is because disable does not disable instancied service for the same reason enable doe not enable them). Or activate/desactivate. But whatever the name, there is going to be some ugly interactions with enable/disable. (We would want desactivate to match globs too in order to be able to desactivate older instances, but then how do we check which has precedence between enable/disable/activate/desactivate). Maybe it is instead way easier to just directly call systemctl enable. Still, one feature missing is the ability to desactivate all services files (systemctl preset-all leaves the instances alone even with a disable *) in order to go back to a 'pristine' state from which one can call systemctl preset-all and then enable the instances. -- Damien Robert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [Question/bug] Timeout after bus_event_loop_with_idle() change.
Hi, With current git and since 430e21c2f7e77d600257ead56419f51 i keep on getting timeout on these units dbuch@dbuch-laptop ~/dev/systemd (git)-[master] % systemctl --failed UNIT LOAD ACTIVE SUBDESCRIPTION ● systemd-hostnamed.service loaded failed failed Hostname Service ● systemd-localed.service loaded failed failed Locale Service ● systemd-timedated.service loaded failed failed Time Date Service My build config looks like this: --libexecdir=/usr/lib \ --localstatedir=/var \ --sysconfdir=/etc \ --enable-introspection \ --enable-gtk-doc \ --enable-kdbus \ --enable-compat-libs \ --enable-timesyncd \ --enable-lz4 \ --enable-terminal \ --enable-resolved \ --disable-audit \ --disable-ima \ --disable-multi-seat-x \ --disable-smack \ --with-sysvinit-path= \ --with-sysvrcnd-path= \ --with-firmware-path=/usr/lib/firmware/updates:/usr/lib/firmware \ Am i missing something? I havn't yet found any solution yet, and journal isn't helping me much here. Best regards, Daniel. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [uml-devel] Timed out waiting for device dev-disk-by...
On Fri, Oct 03, 2014 at 07:14:51PM +0200, Thomas Meyer wrote: Hmm ... one of common reason for such problems recently was missing CONFIG_FHANDLE in kernel configuration. Could you verify that all required kernel options are set in your case? Hi Andrei, Thanks for this tip! My kernel config did indeed miss the CONFIG_FHANDLE option. After recompiling the kernel, the devices where automatically detected by systemd! Does systemd log a message somewhere about this missing kernel option? Did I miss the relevant notice in the log messages? You have missed README. -- Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.'' xmpp: zdzich...@chrome.pl -- Mitchell Blank on LKML ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Added test for unit file state returned by unit_file_get_state and unit_file_get_list.
--- .gitignore | 1 + Makefile.am| 44 ++- src/test/test-enabled.c| 143 + .../etc/systemd/system/masked.service | 1 + .../etc/systemd/system/maskedstatic.service| 1 + .../etc/systemd/system/some.target | 15 +++ .../system/some.target.wants/aliased.service | 1 + .../system/some.target.wants/also_masked.service | 1 + .../system/some.target.wants/another.service | 1 + .../system/some.target.wants/different.service | 1 + .../system/some.target.wants/masked.service| 1 + .../some.target.wants/templating@four.service | 1 + .../some.target.wants/templating@one.service | 1 + .../some.target.wants/templating@three.service | 1 + .../some.target.wants/templating@two.service | 1 + .../run/systemd/system/maskedruntime.service | 1 + .../run/systemd/system/maskedruntimestatic.service | 1 + .../run/systemd/system/other.target| 15 +++ .../system/other.target.wants/runtime.service | 1 + .../usr/lib/systemd/system/another.service | 12 ++ .../usr/lib/systemd/system/disabled.service| 12 ++ .../usr/lib/systemd/system/invalid.service | 1 + .../usr/lib/systemd/system/masked.service | 12 ++ .../usr/lib/systemd/system/maskedruntime.service | 12 ++ .../lib/systemd/system/maskedruntimestatic.service | 9 ++ .../usr/lib/systemd/system/maskedstatic.service| 9 ++ .../usr/lib/systemd/system/runtime.service | 12 ++ .../usr/lib/systemd/system/static.service | 9 ++ .../usr/lib/systemd/system/templating@.service | 12 ++ .../lib/systemd/system/templating@three.service| 12 ++ .../usr/lib/systemd/system/templating@two.service | 12 ++ .../usr/lib/systemd/system/unique.service | 12 ++ 32 files changed, 365 insertions(+), 3 deletions(-) create mode 100644 src/test/test-enabled.c create mode 12 test/test-enabled-root/etc/systemd/system/masked.service create mode 12 test/test-enabled-root/etc/systemd/system/maskedstatic.service create mode 100644 test/test-enabled-root/etc/systemd/system/some.target create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/aliased.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/also_masked.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/another.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/different.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/masked.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/templating@four.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/templating@one.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/templating@three.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/templating@two.service create mode 12 test/test-enabled-root/run/systemd/system/maskedruntime.service create mode 12 test/test-enabled-root/run/systemd/system/maskedruntimestatic.service create mode 100644 test/test-enabled-root/run/systemd/system/other.target create mode 12 test/test-enabled-root/run/systemd/system/other.target.wants/runtime.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/another.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/disabled.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/invalid.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/masked.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/maskedruntime.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/maskedruntimestatic.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/maskedstatic.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/runtime.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/static.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/templating@.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/templating@three.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/templating@two.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/unique.service diff --git a/.gitignore b/.gitignore index f119b57..97b2b2b 100644 --- a/.gitignore +++ b/.gitignore @@ -173,6 +173,7 @@ /test-icmp6-rs /test-ellipsize /test-engine +/test-enabled /test-env-replace /test-event /test-fdset diff --git a/Makefile.am b/Makefile.am index 60011b7..3d782fa 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1355,7
Re: [systemd-devel] [PATCH] Small cleanup for systemd-fstab-generator
On Fri, Oct 03, 2014 at 04:53:47PM +0200, Tobias Hunger wrote: From 4d038e78cd9656712a74901e0b6c79184764e7c1 Mon Sep 17 00:00:00 2001 From: Tobias Hunger tobias.hun...@digia.com Date: Fri, 3 Oct 2014 16:29:30 +0200 Subject: [PATCH 1/2] fstab-generator: Small cleanup Applied. Please use git-send-email in the future. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd.exec man question SecureBits= a list?
It says: Takes a list of strings can you be more precise? [string,string] string string string,string what is a list in this case? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd.exec man question SecureBits= a list?
On Sat, Oct 04, 2014 at 02:52:09AM +0200, Darko Luketic wrote: It says: Takes a list of strings can you be more precise? [string,string] string string string,string what is a list in this case? Space separated. I updated the man page too. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [uml-devel] Timed out waiting for device dev-disk-by...
В Wed, 01 Oct 2014 00:47:08 +0600 Alexander E. Patrakov patra...@gmail.com пишет: 01.10.2014 00:27, Thomas Meyer wrote: Am Montag, den 29.09.2014, 22:20 +0200 schrieb Richard Weinberger: On Mon, Sep 29, 2014 at 8:29 PM, Thomas Meyer tho...@m3y3r.de wrote: Hi, I get a timeout in the Fedora 21 alpha: [ TIME ] Timed out waiting for device dev-disk-by\x2duuid-008af19d\x2d2562\x2d49bd\x2d8907\x2d721ea08f3e14.device. ... Imho the problem is not specific to UML. Something similar has been triggered on my desktop PC, and nobody replied: https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg22490.html If this triggers again, I will provide dumps. Well, your problem seems to be entirely different. Here device links are created but systemd does not get notification about them. In your case device links are missing which usually means something wrong with udev rules. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Added test for unit file state returned by unit_file_get_state and unit_file_get_list.
Just to give some context, at Pantheon, we're working on optimizations for the enabled part of systemd core. The first step we're doing is enhancing the test suite. The additions here pass on master and will also pass with the changes we'll submit after more tests are in core. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] A way to better integrate rsyslog into systemd?
With all the recent noise about systemd abusing its position with the way it takes over logging I’ve been thinking about a way to solve it. As far as I understand the following holds: - Systemd takes over /dev/log socket which is normally served by rsyslog (or other syslog daemon). - That’s really required to make journald-based logging transparent and coherent for most use-cases. However, it creates a problem for log-heavy applications, because of additional roundtrips between processes. So far I’ve heard people actually using LD_PRELOAD tricks to hack around applications opening the /dev/log file inside the syslog(2). As far as I understand, it’s also not really configurable - the '/dev/log’ string is hardcoded into various libcs (e.g.: http://git.musl-libc.org/cgit/musl/tree/src/misc/syslog.c). Recent versions of rsyslog can directly read journald files. But that’s still suboptimal solution, because it introduces an unnecessary layer. Namespacing each daemon to provide its own /dev tree with custom /dev/log sockets is possible, but impractical. So I propose the following solution: 1) Add an option to systemd units to allow passing opened /dev/log sockets to rsyslog (using the usual SOL_SOCKET mechanism). 2) Add the corresponding functionality to rsyslog. It should listen on a special socket (perhaps /run/rsyslog/socket_server ?) and treat all the incoming sockets as if they were accepted from /dev/log. It would also solve the problems with rsyslog using its own SCM_CREDENTIALS lookups.___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
