[systemd-devel] [PATCH] journald: Introduce RFC 5424 syslog
This patch adds support for RFC 5424 syslog format to journald. Journald
can now forward logs to a multicast UDP group.
RFC 5424 format:
VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP
[SD-ID]s SP MSG
Example conf:
file: journald.conf
SysLogAddress=239.0.0.1:6000
---
Makefile.am | 1 +
man/journald.conf.xml | 12 ++
src/journal/journald-gperf.gperf | 1 +
src/journal/journald-native.c | 3 +
src/journal/journald-server.c | 40 +-
src/journal/journald-server.h | 14 ++
src/journal/journald-stream.c | 4 +
src/journal/journald-syslog-network.c | 246 ++
src/journal/journald-syslog.c | 3 +
src/journal/journald-syslog.h | 2 +
10 files changed, 325 insertions(+), 1 deletion(-)
create mode 100644 src/journal/journald-syslog-network.c
diff --git a/Makefile.am b/Makefile.am
index ba63f68..b015f69 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4487,6 +4487,7 @@ libsystemd_journal_core_la_SOURCES = \
src/journal/journald-kmsg.h \
src/journal/journald-syslog.c \
src/journal/journald-syslog.h \
+ src/journal/journald-syslog-network.c \
src/journal/journald-stream.c \
src/journal/journald-stream.h \
src/journal/journald-server.c \
diff --git a/man/journald.conf.xml b/man/journald.conf.xml
index 364b58f..4fb037b 100644
--- a/man/journald.conf.xml
+++ b/man/journald.conf.xml
@@ -355,6 +355,18 @@
+SysLogAddress=
+Controls whether log messages received by the
+journal daemon shall be forwarded to a multicast UDP network
+group in syslog RFC 5424 format.
+
+The the address string format is similar to socket units. See
+
systemd.socket1
+
+
+
+
+
TTYPath=
Change the console TTY to use if
diff --git a/src/journal/journald-gperf.gperf b/src/journal/journald-gperf.gperf
index 74554c1..9cdffbc 100644
--- a/src/journal/journald-gperf.gperf
+++ b/src/journal/journald-gperf.gperf
@@ -40,3 +40,4 @@ Journal.MaxLevelKMsg, config_parse_log_level, 0,
offsetof(Server, max_lev
Journal.MaxLevelConsole,config_parse_log_level, 0, offsetof(Server,
max_level_console)
Journal.MaxLevelWall, config_parse_log_level, 0, offsetof(Server,
max_level_wall)
Journal.SplitMode, config_parse_split_mode, 0, offsetof(Server,
split_mode)
+Journal.SysLogAddress, config_parse_syslog_network_address, 0,
offsetof(Server, syslog_addr)
diff --git a/src/journal/journald-native.c b/src/journal/journald-native.c
index 851625d..9fd370f 100644
--- a/src/journal/journald-native.c
+++ b/src/journal/journald-native.c
@@ -273,6 +273,9 @@ void server_process_native_message(
if (s->forward_to_syslog)
server_forward_syslog(s, priority, identifier,
message, ucred, tv);
+if (s->forward_to_network)
+server_forward_syslog_network(s, priority, identifier,
message, ucred, tv);
+
if (s->forward_to_kmsg)
server_forward_kmsg(s, priority, identifier, message,
ucred);
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index 7ee8174..de4ef50 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -86,7 +86,7 @@ static const char* const split_mode_table[_SPLIT_MAX] = {
DEFINE_STRING_TABLE_LOOKUP(split_mode, SplitMode);
DEFINE_CONFIG_PARSE_ENUM(config_parse_split_mode, split_mode, SplitMode,
"Failed to parse split mode setting");
-static uint64_t available_space(Server *s, bool verbose) {
+uint64_t available_space(Server *s, bool verbose) {
char ids[33];
_cleanup_free_ char *p = NULL;
sd_id128_t machine;
@@ -1356,6 +1356,35 @@ static int server_parse_config_file(Server *s) {
false, s);
}
+int config_parse_syslog_network_address(const char *unit,
+const char *filename,
+unsigned line,
+const char *section,
+unsigned section_line,
+const char *lvalue,
+int ltype,
+const char *rvalue,
+void *data,
+void *userdata) {
+Server *s = userdata;
+int r;
+
+assert(filename);
+assert(lvalue);
+assert(rvalue);
+assert(data);
+
+r = socket_address_parse(&s->syslog_addr, rvalue);
+if (r < 0) {
+log_syntax(unit, LOG_ERR, filename, line, -r,
+ "Failed to parse address value, ignoring: %s",
rvalue);
+return 0;
+
Re: [systemd-devel] [PATCH] option to ignore ENOMEDIUM in blkid
On Tue, Feb 17, 2015 at 12:06 AM, Oliver Neukum wrote:
>
> On Mon, 2015-02-16 at 14:52 -0800, Hans Scholze wrote:
> > 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
> >
> That seems to be the error. You cannot guarantee that blkid will never
> see this error if the drive has removable media. It should have an
> option for silently failing in these cases.
Sounds like a good idea to me but I am not too familiar with the code.
How about this?
From 8e1994f37169a95134a73a21efecceb1a13cc28a Mon Sep 17 00:00:00 2001
From: Hans Scholze
Date: Wed, 18 Feb 2015 23:13:12 -0800
Subject: [PATCH 1/2] Add option to silently ignore ENOMEDIUM to udev builtin
blkid.
---
src/udev/udev-builtin-blkid.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/udev/udev-builtin-blkid.c b/src/udev/udev-builtin-blkid.c
index 810f27d..ac70827 100644
--- a/src/udev/udev-builtin-blkid.c
+++ b/src/udev/udev-builtin-blkid.c
@@ -217,6 +217,7 @@ static int builtin_blkid(struct udev_device *dev, int argc, char *argv[], bool t
const char *root_partition;
int64_t offset = 0;
bool noraid = false;
+bool ignore_enomedium = false;
_cleanup_close_ int fd = -1;
blkid_probe pr;
const char *data;
@@ -229,13 +230,14 @@ static int builtin_blkid(struct udev_device *dev, int argc, char *argv[], bool t
static const struct option options[] = {
{ "offset", optional_argument, NULL, 'o' },
{ "noraid", no_argument, NULL, 'R' },
+{ "ignore-enomedium", no_argument, NULL, 'q' },
{}
};
for (;;) {
int option;
-option = getopt_long(argc, argv, "oR", options, NULL);
+option = getopt_long(argc, argv, "oRq", options, NULL);
if (option == -1)
break;
@@ -246,6 +248,9 @@ static int builtin_blkid(struct udev_device *dev, int argc, char *argv[], bool t
case 'R':
noraid = true;
break;
+case 'q':
+ignore_enomedium = true;
+break;
}
}
@@ -263,7 +268,8 @@ static int builtin_blkid(struct udev_device *dev, int argc, char *argv[], bool t
fd = open(udev_device_get_devnode(dev), O_RDONLY|O_CLOEXEC);
if (fd < 0) {
-fprintf(stderr, "error: %s: %m\n", udev_device_get_devnode(dev));
+if(!(ignore_enomedium && errno == ENOMEDIUM))
+fprintf(stderr, "error: %s: %m\n", udev_device_get_devnode(dev));
goto out;
}
--
2.3.0
From 73992d2ee525a3fccf476c15f2522259027ca59e Mon Sep 17 00:00:00 2001
From: Hans Scholze
Date: Wed, 18 Feb 2015 23:14:30 -0800
Subject: [PATCH 2/2] Ignore ENOMEDIUM in blkidduring persistent storage naming
to prevent empty removable devices from causing spurious error messages.
---
rules/60-persistent-storage.rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rules/60-persistent-storage.rules b/rules/60-persistent-storage.rules
index 475b151..3ba4fcd 100644
--- a/rules/60-persistent-storage.rules
+++ b/rules/60-persistent-storage.rules
@@ -67,7 +67,7 @@ KERNEL=="sr*", ENV{DISK_EJECT_REQUEST}!="?*", ENV{ID_CDROM_MEDIA_TRACK_COUNT_DAT
IMPORT{builtin}="blkid --noraid"
# probe filesystem metadata of disks
-KERNEL!="sr*", IMPORT{builtin}="blkid"
+KERNEL!="sr*", IMPORT{builtin}="blkid --ignore-enomedium"
# watch metadata changes by tools closing the device after writing
KERNEL!="sr*", OPTIONS+="watch"
--
2.3.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] hwdb: fix ThinkPad X6* Tablet special keys
Hey Lubomir, Lubomir Rintel [2015-02-18 21:02 +0100]: > Some (all? -- an equivalent rule exists for X200t already) ThinkPad tablet > firmware has DMI product name and version reversed: > > Handle 0x0001, DMI type 1, 27 bytes > System Information > Manufacturer: LENOVO > Product Name: 7762AS1 > Version: ThinkPad X61 Tablet Thanks for pointing out! This indeed seems to be the case for other ThinkPads as well: $ cat /sys/class/dmi/id/product_name 2324CTO $ cat /sys/class/dmi/id/product_version ThinkPad X230 So I updated your patch slightly, and adjusted the commit message a bit: http://cgit.freedesktop.org/systemd/systemd/commit/?id=39addb81 Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] po: update Russian translation
Hey Sergey, Sergey Ptashnick [2015-02-19 3:32 +0300]: > Add strings for fsckd. Applied, thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev won't rename interfaces that are already UP
В Wed, 18 Feb 2015 21:48:48 +0100 Tom Gundersen пишет: > On Wed, Feb 18, 2015 at 9:36 PM, Reindl Harald wrote: > > Am 18.02.2015 um 21:29 schrieb Giancarlo Razzolini: > >> It is my perception that if you are using predictable network interface > >> naming, which is the current default, you can safely make your network > >> configuration use the changed interfaces names to be sure they'll get > >> the desired interface. This applies to network configuration, firewall > >> rules, whatever > > > > predictable? go away! > > I think you know he was referring to: > http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ > > Maybe you disagree with the use of the word 'predictable', but that's > what the scheme is called, so let's just stick to that (maybe thinking > of it as 'deterministic' would make it more palatable). > What's wrong with renaming it if we agree that name was chosen badly^Wsuboptimal? Unless this is deliberate marketing decision of course. > > on any machine i know running network.service (the old style) > > ethX is predictable and the new "predictable" changed multiple times and > > frankly there are configurations re-used on a dozens of machines where i > > know in case of *all of them* that eth1 is *always* the WAN interface > > Good. Then disable the logic. But please understand that in general it > is not possible to know whether eth0/eth1 will be switched between > reboots. Our default logic must work in general, not only on specific > machines, which is why it is the way it is. > Come on, persistent interface names, including topology based name assignment, was possible and in use long before this new scheme was invented. New scheme is not about "predictability" but about removing need to rename interfaces. The only real justification is "trying to assign the interface name raced against the kernel assigning new names from the same "ethX" namespace". From user point of view it sounds "we (developers) were not able to solve this problem so we decided to make it your (users) problem". ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] fix build against v3.20-rc1
--- fs.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs.c b/fs.c index 22ca62b..f751392 100644 --- a/fs.c +++ b/fs.c @@ -208,7 +208,6 @@ static struct inode *fs_inode_get(struct super_block *sb, inode->i_private = kdbus_node_ref(node); inode->i_mapping->a_ops = &empty_aops; - inode->i_mapping->backing_dev_info = &noop_backing_dev_info; inode->i_mode = node->mode & S_IALLUGO; inode->i_atime = inode->i_ctime = inode->i_mtime = CURRENT_TIME; inode->i_uid = node->uid; -- 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] po: update Russian translation
Add strings for fsckd. --- po/ru.po |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/po/ru.po b/po/ru.po index f07f333..1ffeec6 100644 --- a/po/ru.po +++ b/po/ru.po @@ -7,7 +7,7 @@ msgstr "" "Project-Id-Version: systemd\n" "Report-Msgid-Bugs-To: 0comff...@inbox.ru\n" "POT-Creation-Date: 2013-03-24 19:22+0300\n" -"PO-Revision-Date: 2015-01-23 20:55+0300\n" +"PO-Revision-Date: 2015-02-19 03:27+0300\n" "Last-Translator: Sergey Ptashnick <0comff...@inbox.ru>\n" "Language: ru\n" "MIME-Version: 1.0\n" @@ -328,11 +328,11 @@ msgstr "Чтобы заставить systemd перечитать конфиг #: ../src/fsckd/fsckd.c:186 msgid "Press Ctrl+C to cancel all filesystem checks in progress" -msgstr "" +msgstr "Чтобы прервать все запущенные проверки файловых систем, нажмите Ctrl+C" #: ../src/fsckd/fsckd.c:227 #, c-format msgid "Checking in progress on %d disk (%3.1f%% complete)" msgid_plural "Checking in progress on %d disks (%3.1f%% complete)" -msgstr[0] "" -msgstr[1] "" +msgstr[0] "Проверяется целостность файловой системы на %d диске (выполнено %3.1f%%)" +msgstr[1] "Проверяется целостность файловых систем на %d дисках (выполнено %3.1f%%)" -- 1.7.2.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: add configure option to disable LTO/gold
2015-02-19 0:39 GMT+01:00 Zbigniew Jędrzejewski-Szmek : > On Wed, Feb 18, 2015 at 11:52:50PM +0100, Michael Biebl wrote: >> 2015-02-18 20:34 GMT+01:00 Lennart Poettering : >> > Well, why patch anything? You already have a configure option, just by >> > adding LDFLAGS= and CFLAGS= to the end of the configure line. What's >> > the point of having an explicit option for that? >> >> What is the reason to override the default linker anyway? systemd >> really shouldn't do that. > > To encourage the adoption of a more modern pipeline? The ./configure option > to switch the linker is trivial, so I don't see why this is such an issue. Are we going to enforce the use of LLVM next? Really, the use choice of the linker should be left to the ones building the package, i.e. the distros in most cases. Incidentally, we do have to remove the -Wl,-fuse-ld=gold line in Debian as well, since gold is problematic/less mature on various architectures. Couldn't we just add -Wl,-fuse-ld=gold via LDFLAGS in autogen.sh? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: add configure option to disable LTO/gold
On Wed, Feb 18, 2015 at 11:52:50PM +0100, Michael Biebl wrote: > 2015-02-18 20:34 GMT+01:00 Lennart Poettering : > > Well, why patch anything? You already have a configure option, just by > > adding LDFLAGS= and CFLAGS= to the end of the configure line. What's > > the point of having an explicit option for that? > > What is the reason to override the default linker anyway? systemd > really shouldn't do that. To encourage the adoption of a more modern pipeline? The ./configure option to switch the linker is trivial, so I don't see why this is such an issue. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: add configure option to disable LTO/gold
2015-02-18 20:34 GMT+01:00 Lennart Poettering : > Well, why patch anything? You already have a configure option, just by > adding LDFLAGS= and CFLAGS= to the end of the configure line. What's > the point of having an explicit option for that? What is the reason to override the default linker anyway? systemd really shouldn't do that. -- 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] Udev won't rename interfaces that are already UP
On 18-02-2015 19:23, Lennart Poettering wrote: > Well, if you have networking up so early that's usually because you > need it to boot, for example because it is the backing device for the > root file system. In such a case it would be a really bad idea to take > the network interface down. This is the most common usage for early networking, yes. But there are many others, as my hooks demonstrate. > > I think generally the deal is pretty OK and kinda expected: if you > want early networking, then you have to stick with the name you choose > that early. > > I figure if you want control over naming of the interfaces, the right > option would be to include the .link file for it in the initrd image, > so that it is applied that early. I don't want any control over the naming of the interfaces. The current system is ok, in my opinion. I just think, given an option, udev could rename all interfaces regardless of their status. I already handle this in the initramfs, but I wanted to check if there was a way for udev to change their names. I now know that it doesn't and there isn't much appeal for introducing this functionality in it. Sorry for the noise and if I stepped on anyone's toes. Cheers, Giancarlo Razzolini ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev won't rename interfaces that are already UP
On Wed, 18.02.15 18:26, Giancarlo Razzolini (grazzol...@gmail.com) wrote: > On 18-02-2015 18:12, Mantas Mikulėnas wrote: > > It's so much not that udev won't do this – the kernel actually won't > > let it to: > > > > # ip link set eth0 up > > # ip link set eth0 name fred0 > > RTNETLINK answers: Device or resource busy > > # > > > Thank you for your fast response, Mantas. I'm aware that this is a > kernel limitation. But udev could force the renaming by intentionally > flushing and/or downing the interface. I know this is a corner case, but > I believe that the early userspace network configuration should be > forcibly dropped, no matter what. Also, I know that early userspace > networking isn't common place, but it has many applications, as those > hooks show. I'd be happy to give a try in making a patch, but I wanted > first to get some input from you guys. Well, if you have networking up so early that's usually because you need it to boot, for example because it is the backing device for the root file system. In such a case it would be a really bad idea to take the network interface down. I think generally the deal is pretty OK and kinda expected: if you want early networking, then you have to stick with the name you choose that early. I figure if you want control over naming of the interfaces, the right option would be to include the .link file for it in the initrd image, so that it is applied that early. 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] tmpfiles.d specifier support on "argument" when operating on files
El 18/02/15 a las 07:10, Lennart Poettering escribió:
On Tue, 17.02.15 17:35, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
Please fix this for all arguments, not just symlinks.
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index c948d4d..1b35b8e 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1590,6 +1590,12 @@ static int parse_line(const char *fname, unsigned line,
const char *buffer) {
i.argument = strappend("/usr/share/factory/", i.path);
if (!i.argument)
return log_oom();
+} else {
+r = specifier_printf(i.argument,
specifier_table, NULL, &i.argument);
Here's a memory leak, you need to free the old i.argument.
Indentation! Please have a look at CODING_STYLE. You need to indent by
8ch. 4ch indenting is not acceptable.
+if (r < 0) {
+log_error("[%s:%u] Failed to replace specifiers: %s",
fname, line, path);
+return r;
+}
HI again:
Is the attached version cool for you ?
>From ee8e4f440def745b6f0655b897e65d48321e46c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cristian=20Rodr=C3=ADguez?=
Date: Wed, 18 Feb 2015 18:09:16 -0300
Subject: [PATCH] tmpfiles: implement specifier substitution for file
"argument"
Only for L and C types where it makes sense.
---
src/tmpfiles/tmpfiles.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 88ba7e4..6de477b 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1568,6 +1568,18 @@ static int parse_line(const char *fname, unsigned line, const char *buffer) {
}
}
+if(IN_SET(i.type, CREATE_SYMLINK, COPY_FILES)) {
+if(i.argument) {
+_cleanup_free_ char *resolved_iarg = NULL;
+r = specifier_printf(i.argument, specifier_table, NULL, &resolved_iarg);
+if(r < 0)
+return log_error_errno(r, "[%s:%u] Failed to replace specifiers: %s", fname, line, path);
+r = free_and_strdup(&i.argument, resolved_iarg);
+if(r < 0)
+return log_oom();
+}
+}
+
switch (i.type) {
case CREATE_FILE:
--
2.3.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev won't rename interfaces that are already UP
On 18-02-2015 19:11, Reindl Harald wrote: > and since you say *this* is an exception you can be sure that you > could find enough people point to this and that which explains why it > is a bad idea - implement something which changes existing behavior > and needs exceptions right from the start is doomed to fail in the > long run In my first e-mail I said this could be an option handle to udevd used set by people that (hopefully) understands what he/she is doing. Not necessarily could be a default. It was just a proposition. Cheers, Giancarlo Razzolini smime.p7s Description: Assinatura criptográfica S/MIME ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev won't rename interfaces that are already UP
Am 18.02.2015 um 21:58 schrieb Giancarlo Razzolini: On 18-02-2015 18:49, Reindl Harald wrote: that won't change the fact that if *anybody* comes to the idea to take an interface which *is up* down for rename it should get removed any commit permissions instantaneously because he don't care about *a ton* of implications depending on the local environment doing so First of all, I'm not a systemd dev. Nor want to be. Secondly, I believe you didn't really understood my proposition. You are talking about userspace *after* initramfs and *after* systemd is initialized and renamed (or not) any interface. Of course systemd should *never* mess with an interface *after* system initialization. But it can do anything *right after* the initramfs hand the control to systemd. Of course except if the interface is up for a nfsroot. In this case the renaming shouldn't happen. But this is an exception and since you say *this* is an exception you can be sure that you could find enough people point to this and that which explains why it is a bad idea - implement something which changes existing behavior and needs exceptions right from the start is doomed to fail in the long run 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] Udev won't rename interfaces that are already UP
On Wed, Feb 18, 2015 at 9:58 PM, Giancarlo Razzolini wrote: > You are talking about userspace > *after* initramfs and *after* systemd is initialized and renamed (or not) > any interface. Of course systemd should *never* mess with an interface > *after* system initialization. But it can do anything *right after* the > initramfs hand the control to systemd. Of course except if the interface is > up for a nfsroot. In this case the renaming shouldn't happen. But this is an > exception. We cannot know in udev why an interface is UP. I would say that if your initramfs brings an interface up it should take it back down again if it is not needed any longer (in most cases I guess it _will_ be needed). Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev won't rename interfaces that are already UP
On 18-02-2015 18:49, Reindl Harald wrote: > that won't change the fact that if *anybody* comes to the idea to take > an interface which *is up* down for rename it should get removed any > commit permissions instantaneously because he don't care about *a ton* > of implications depending on the local environment doing so > First of all, I'm not a systemd dev. Nor want to be. Secondly, I believe you didn't really understood my proposition. You are talking about userspace *after* initramfs and *after* systemd is initialized and renamed (or not) any interface. Of course systemd should *never* mess with an interface *after* system initialization. But it can do anything *right after* the initramfs hand the control to systemd. Of course except if the interface is up for a nfsroot. In this case the renaming shouldn't happen. But this is an exception. Cheers, Giancarlo Razzolini ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev won't rename interfaces that are already UP
Am 18.02.2015 um 21:40 schrieb Giancarlo Razzolini: On 18-02-2015 18:36, Reindl Harald wrote: predictable? go away! This does not reflect the default behavior systemd-udevd and I believe it is your *personal* opinion. on any machine i know running network.service (the old style) ethX is predictable and the new "predictable" changed multiple times and frankly there are configurations re-used on a dozens of machines where i know in case of *all of them* that eth1 is *always* the WAN interface I'm aware of this. But in this case if you do not use the predictable system, you won't be affected by this discussion that won't change the fact that if *anybody* comes to the idea to take an interface which *is up* down for rename it should get removed any commit permissions instantaneously because he don't care about *a ton* of implications depending on the local environment doing so 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] Udev won't rename interfaces that are already UP
On Wed, Feb 18, 2015 at 9:36 PM, Reindl Harald wrote: > Am 18.02.2015 um 21:29 schrieb Giancarlo Razzolini: >> It is my perception that if you are using predictable network interface >> naming, which is the current default, you can safely make your network >> configuration use the changed interfaces names to be sure they'll get >> the desired interface. This applies to network configuration, firewall >> rules, whatever > > predictable? go away! I think you know he was referring to: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ Maybe you disagree with the use of the word 'predictable', but that's what the scheme is called, so let's just stick to that (maybe thinking of it as 'deterministic' would make it more palatable). > on any machine i know running network.service (the old style) > ethX is predictable and the new "predictable" changed multiple times and > frankly there are configurations re-used on a dozens of machines where i > know in case of *all of them* that eth1 is *always* the WAN interface Good. Then disable the logic. But please understand that in general it is not possible to know whether eth0/eth1 will be switched between reboots. Our default logic must work in general, not only on specific machines, which is why it is the way it is. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev won't rename interfaces that are already UP
On Wed, Feb 18, 2015 at 9:10 PM, Giancarlo Razzolini wrote: > I am currently the maintainer and developer for some archlinux > initramfs tools that deals with early userspace network. More precisely, > I do develop/maintain these hooks: > > https://aur.archlinux.org/packages/dropbear_initrd_encrypt/ > https://aur.archlinux.org/packages/mkinitcpio-ppp/ > > The first make use of the ip= kernel command line parameter and the > latter directly manipulate the desired interface using custom kernel > parameters. But, in both cases, I need to flush the interface and set it > status to DOWN before the initramfs handle the init to systemd. I took a > look at the: src/udev/udev-builtin-net_id.c file and it seems indeed > that it won't rename an interface that is UP. An error is shown in the > journalctl by udev saying the interface couldn't be renamed. I do handle > with this already, but I was wondering if systemd-udevd shouldn't rename > the interface regardless of it state, since the early userspace > interface configuration shouldn't matter after the root is pivoted and > systemd is started. This could be the default or even configurable. What > are your thoughts on this? We cannot (in udev) put an interface DOWN, as there is probably some reason it was UP in the first place. Maybe your rootfs is nfs, or some other such crucial service is running over the link. As the link cannot be brought down the kernel will not allow us to rename it. Moreover, we shouldn't be renaming an in-use interface anyway. The intended use of the rename logic is that links are renamed exactly once, and that is before they are ever used by userspace. If you use the links in the initrd then any renaming should be happening in the initrd before the links are used. Anything else will not be safe. I hope that makes sense. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev won't rename interfaces that are already UP
On 18-02-2015 18:36, Reindl Harald wrote: > predictable? go away! This does not reflect the default behavior systemd-udevd and I believe it is your *personal* opinion. > > on any machine i know running network.service (the old style) > ethX is predictable and the new "predictable" changed multiple times > and frankly there are configurations re-used on a dozens of machines > where i know in case of *all of them* that eth1 is *always* the WAN > interface I'm aware of this. But in this case if you do not use the predictable system, you won't be affected by this discussion. Cheers, Giancarlo Razzolini smime.p7s Description: Assinatura criptográfica S/MIME ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev won't rename interfaces that are already UP
Am 18.02.2015 um 21:29 schrieb Giancarlo Razzolini: On 18-02-2015 18:19, Reindl Harald wrote: and hopefully that keeps this way * configurations rely on eth0, eth1... exists Didn't you mean en, wl, etc? no, i mean what i say * they are sane and fine * firewall rules may depend on them It is my perception that if you are using predictable network interface naming, which is the current default, you can safely make your network configuration use the changed interfaces names to be sure they'll get the desired interface. This applies to network configuration, firewall rules, whatever predictable? go away! on any machine i know running network.service (the old style) ethX is predictable and the new "predictable" changed multiple times and frankly there are configurations re-used on a dozens of machines where i know in case of *all of them* that eth1 is *always* the WAN interface 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] Udev won't rename interfaces that are already UP
On 18-02-2015 18:19, Reindl Harald wrote: > and hopefully that keeps this way > > * configurations rely on eth0, eth1... exists Didn't you mean en, wl, etc? > * they are sane and fine > * firewall rules may depend on them It is my perception that if you are using predictable network interface naming, which is the current default, you can safely make your network configuration use the changed interfaces names to be sure they'll get the desired interface. This applies to network configuration, firewall rules, whatever. Cheers, Giancarlo Razzolini smime.p7s Description: Assinatura criptográfica S/MIME ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev won't rename interfaces that are already UP
On 18-02-2015 18:12, Mantas Mikulėnas wrote: > It's so much not that udev won't do this – the kernel actually won't > let it to: > > # ip link set eth0 up > # ip link set eth0 name fred0 > RTNETLINK answers: Device or resource busy > # > Thank you for your fast response, Mantas. I'm aware that this is a kernel limitation. But udev could force the renaming by intentionally flushing and/or downing the interface. I know this is a corner case, but I believe that the early userspace network configuration should be forcibly dropped, no matter what. Also, I know that early userspace networking isn't common place, but it has many applications, as those hooks show. I'd be happy to give a try in making a patch, but I wanted first to get some input from you guys. Cheers, Giancarlo Razzolini ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3] analyze: change behaviour of combined --to/from--pattern
On 14.02.2015 00:53, Zbigniew Jędrzejewski-Szmek wrote: > We would require a match against all three: patterns specified > with --to, with --from, and as positional arguments to show an > edge. This does not seem useful. Let instead the positional args > behave like they were specified in both --to and --from, which is > fairly intuitive and should be more useful. I am sure that is exactly what I wanted to achieve with e55933db. :-) -- Było mi bardzo miło. Twoje oczy lubią mnie >Łukasz< i to mnie zgubi (c)SNL 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] Udev won't rename interfaces that are already UP
Am 18.02.2015 um 21:12 schrieb Mantas Mikulėnas: On Wed, Feb 18, 2015 at 10:10 PM, Giancarlo Razzolini mailto:grazzol...@gmail.com>> wrote: But, in both cases, I need to flush the interface and set it status to DOWN before the initramfs handle the init to systemd. I took a look at the: src/udev/udev-builtin-net_id.c file and it seems indeed that it won't rename an interface that is UP. An error is shown in the journalctl by udev saying the interface couldn't be renamed. I do handle with this already, but I was wondering if systemd-udevd shouldn't rename the interface regardless of it state, since the early userspace It's so much not that udev won't do this – the kernel actually won't let it to: # ip link set eth0 up # ip link set eth0 name fred0 RTNETLINK answers: Device or resource busy and hopefully that keeps this way * configurations rely on eth0, eth1... exists * they are sane and fine * firewall rules may depend on them 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] Udev won't rename interfaces that are already UP
On Wed, Feb 18, 2015 at 10:10 PM, Giancarlo Razzolini wrote: > But, in both cases, I need to flush the interface and set it > status to DOWN before the initramfs handle the init to systemd. I took a > look at the: src/udev/udev-builtin-net_id.c file and it seems indeed > that it won't rename an interface that is UP. An error is shown in the > journalctl by udev saying the interface couldn't be renamed. I do handle > with this already, but I was wondering if systemd-udevd shouldn't rename > the interface regardless of it state, since the early userspace > It's so much not that udev won't do this – the kernel actually won't let it to: # ip link set eth0 up # ip link set eth0 name fred0 RTNETLINK answers: Device or resource busy # -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Udev won't rename interfaces that are already UP
Hi all, I am currently the maintainer and developer for some archlinux initramfs tools that deals with early userspace network. More precisely, I do develop/maintain these hooks: https://aur.archlinux.org/packages/dropbear_initrd_encrypt/ https://aur.archlinux.org/packages/mkinitcpio-ppp/ The first make use of the ip= kernel command line parameter and the latter directly manipulate the desired interface using custom kernel parameters. But, in both cases, I need to flush the interface and set it status to DOWN before the initramfs handle the init to systemd. I took a look at the: src/udev/udev-builtin-net_id.c file and it seems indeed that it won't rename an interface that is UP. An error is shown in the journalctl by udev saying the interface couldn't be renamed. I do handle with this already, but I was wondering if systemd-udevd shouldn't rename the interface regardless of it state, since the early userspace interface configuration shouldn't matter after the root is pivoted and systemd is started. This could be the default or even configurable. What are your thoughts on this? Cheers, Giancarlo Razzolini ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] hwdb: fix ThinkPad X6* Tablet special keys
Some (all? -- an equivalent rule exists for X200t already) ThinkPad tablet firmware has DMI product name and version reversed: Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: LENOVO Product Name: 7762AS1 Version: ThinkPad X61 Tablet Serial Number: LKZCDH2 UUID: 6ADBC681-4FC9-11CB-844F-B47CB9210BE2 Wake-up Type: Power Switch SKU Number: Not Specified Family: ThinkPad X61 Tablet --- hwdb/60-keyboard.hwdb | 1 + 1 file changed, 1 insertion(+) diff --git a/hwdb/60-keyboard.hwdb b/hwdb/60-keyboard.hwdb index 1b7d871..cbb80ee 100644 --- a/hwdb/60-keyboard.hwdb +++ b/hwdb/60-keyboard.hwdb @@ -597,6 +597,7 @@ keyboard:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*:pvrThinkPad*X2*Tablet* # ThinkPad X6 Tablet keyboard:dmi:bvn*:bvr*:bd*:svnLENOVO*:pnThinkPad*X6*:pvr* +keyboard:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*:pvrThinkPad*X6*Tablet* KEYBOARD_KEY_6c=direction # rotate KEYBOARD_KEY_68=leftmeta # toolbox KEYBOARD_KEY_6b=esc# escape -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: add configure option to disable LTO/gold
On Wed, 18.02.15 16:25, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: > El 18/02/15 a las 15:58, Lennart Poettering escribió: > >On Wed, 18.02.15 15:45, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: > > > >>LTO may be unreliable, does not work properly in several archs > >>It may crash or produce wrong code. > > > >Well, that's something to fix in the LTO code. > > > >>Compiler developers also said we should not provide production > >>RPM packages with LTO enabled. > > > >We have been doing that for a number of releases on Fedora. Seems to > >work fine. > > Yes, it works in x86_64, except we need to produce working -debuginfo > packages and LTO produces unusable debug infos.. > > Anyway,,currently this is not suitable for us at all. let me explain a > bit... > > Building systemd is affected by this GCC bug (not in fread but *poll) > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 > > We can't just ignore the warnings like "warning: call to ‘__*_chk_warn’ > declared with attribute warning: poll called with fds buffer too small file > nfds entries" why ? The openSUSE buildsystem considers this warnings as > security holes and the package is automatically marked as failed and is > automatically rejected for inclusion. Maybe you should fix your build system then? This is brokeness in gcc, that trips up your build system, and why do you think this should be worked around in systemd? Fix it in gcc, or work-around it in your build system, but we don't want such work-arounds in systemd upstream, sorry. > So we currently disable LTO with a patch, not as nice as the one I posted. Well, why patch anything? You already have a configure option, just by adding LDFLAGS= and CFLAGS= to the end of the configure line. What's the point of having an explicit option for that? 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: add configure option to disable LTO/gold
El 18/02/15 a las 15:58, Lennart Poettering escribió: On Wed, 18.02.15 15:45, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: LTO may be unreliable, does not work properly in several archs It may crash or produce wrong code. Well, that's something to fix in the LTO code. Compiler developers also said we should not provide production RPM packages with LTO enabled. We have been doing that for a number of releases on Fedora. Seems to work fine. Yes, it works in x86_64, except we need to produce working -debuginfo packages and LTO produces unusable debug infos.. Anyway,,currently this is not suitable for us at all. let me explain a bit... Building systemd is affected by this GCC bug (not in fread but *poll) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 We can't just ignore the warnings like "warning: call to ‘__*_chk_warn’ declared with attribute warning: poll called with fds buffer too small file nfds entries" why ? The openSUSE buildsystem considers this warnings as security holes and the package is automatically marked as failed and is automatically rejected for inclusion. So we currently disable LTO with a patch, not as nice as the one I posted. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: add configure option to disable LTO/gold
On Wed, 18.02.15 15:45, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: > LTO may be unreliable, does not work properly in several archs > It may crash or produce wrong code. Well, that's something to fix in the LTO code. > Compiler developers also said we should not provide production > RPM packages with LTO enabled. We have been doing that for a number of releases on Fedora. Seems to work fine. > GOLD also does not work everywhere. Well, that's something to fix in gold. What's wrong with adding CFLAGS=-fno-lto LDFLAGS=-Wl,-fuse-ld=bfd to the end of your configure line? That should be option enough... The thing is that LTO is actually kinda important for us, since we link so much stuff over and over again into many binaries. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build-sys: add configure option to disable LTO/gold
LTO may be unreliable, does not work properly in several archs It may crash or produce wrong code. Compiler developers also said we should not provide production RPM packages with LTO enabled. GOLD also does not work everywhere. --- configure.ac | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index 9a2235b..38194ca 100644 --- a/configure.ac +++ b/configure.ac @@ -207,10 +207,15 @@ AS_CASE([$CC], [*clang*], -Wno-gnu-variable-sized-type-not-at-end \ ])]) -AS_CASE([$CFLAGS], [*-O[[12345\ ]]*], -[CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\ - -flto -ffat-lto-objects])], -[AC_MSG_RESULT([skipping -flto, optimization not enabled])]) +AC_ARG_ENABLE([lto], AS_HELP_STRING([--disable-lto], [Disable Link time optimization])) +AS_IF([test "x$enable_lto" != "xno"], [ +AS_CASE([$CFLAGS], [*-O[[12345\ ]]*], [ +CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [-flto -ffat-lto-objects]) +CC_CHECK_FLAGS_APPEND([with_ldflags], [LDFLAGS],[-Wl,-fuse-ld=gold]) +], +[AC_MSG_RESULT([skipping -flto, optimization not enabled])]) +]) + AC_SUBST([OUR_CFLAGS], "$with_cflags $sanitizer_cflags") AS_CASE([$CFLAGS], [*-O[[12345\ ]]*], @@ -226,7 +231,7 @@ CC_CHECK_FLAGS_APPEND([with_ldflags], [LDFLAGS], [\ -Wl,-z,relro \ -Wl,-z,now \ -pie \ --Wl,-fuse-ld=gold]) +]) AC_SUBST([OUR_LDFLAGS], "$with_ldflags $sanitizer_ldflags") AC_CHECK_SIZEOF(pid_t) -- 2.3.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Looping too fast. Throttling execution a little
> On 18 Feb 2015, at 18:47, Lennart Poettering wrote:
>
> On Wed, 18.02.15 10:41, Thierry Parmentelat (thierry.parmente...@inria.fr)
> wrote:
>
>> root@bigjohn /vservers # journalctl -b -f
>> -- Logs begin at Fri 2014-09-05 04:28:57 CEST. --
>> Feb 18 10:38:25 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
>> Throttling execution a little.
>> Feb 18 10:38:26 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
>> Throttling execution a little.
>> Feb 18 10:38:28 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
>> Throttling execution a little.
>> Feb 18 10:38:30 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
>> Throttling execution a little.
>> Feb 18 10:38:31 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
>> Throttling execution a little.
>> Feb 18 10:38:33 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
>> Throttling execution a little.
>
> THis is happens if for some reason the event loop entered a busy
> loop. It's simply a protection against eating up all CPU forever. It's
> a symptom of another bug, which is the one to track down.
>
>> # strace -p 1
>> <…>
>> recvmsg(42, 0x7fff3ea64d00, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1
>> EAGAIN (Resource temporarily unavailable)
>> timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={0, 1}},
>> NULL) = 0
>> epoll_wait(4, {{EPOLLIN, {u32=3, u64=3}}}, 36, 0) = 1
>> clock_gettime(CLOCK_BOOTTIME, {1959524, 957887776}) = 0
>> read(3, "\1\0\0\0\0\0\0\0", 8) = 8
>> recvmsg(42, 0x7fff3ea64d00, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1
>> EAGAIN (Resource temporarily unavailable)
>> timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={0, 1}},
>> NULL) = 0
>> epoll_wait(4, {{EPOLLIN, {u32=3, u64=3}}}, 36, 0) = 1
>> clock_gettime(CLOCK_BOOTTIME, {1959524, 958282696}) = 0
>> read(3, "\1\0\0\0\0\0\0\0", 8) = 8
>> recvmsg(42, 0x7fff3ea64d00, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1
>> EAGAIN (Resource temporarily unavailable)
>> timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={0, 1}},
>> NULL) = 0
>> epoll_wait(4, {{EPOLLIN, {u32=3, u64=3}}}, 36, 0) = 1
>> clock_gettime(CLOCK_BOOTTIME, {1959524, 958617432}) = 0
>> ^CProcess 1 detached
>
> Hmm, this appears to be caused by a timer that is not reset. First the
> timer fd is set to the earliest possible trigger, then epoll_wait() is
> entered, which immediately quites. Then the tiemrfd elapse counter is
> read which is 1.
>
> It would be interesting to figure out which timer this is.
>
> To make this work, can you reproduce the issue, then use gdb:
>
> 1. Type "gdb" to start it
> 2. Type "attach 1" to attach to PID 1
> 3. Type "b source_dispatch" to set a break point on the source_dispatch
> function
> 4. Type "c" to continue execution
> 5. This should then break on the next execution of the source_dispatch
> function
> 6. This should happen immediately, after all PID 1 is busy looping
> around a timer. Use "p s->description" to get a short description
> string for the event that is being dispatched. In fact, please use
> "p *s" to get all data about the event, and paste it here.
>
> Thanks!
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
OK, I’ll do this next time the box enters that state
Thanks — Thierry
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Errors using machinectl pull-tar and machinectl pull-dkr
On Tue, 17.02.15 16:48, Peter Paule (systemd-de...@fedux.org) wrote: > > Hi there, > > I tried "machinectl" from systemd 219 on Arch Linux (testing) today: I got > two errors. Should we discuss this here or should I open a Bug Report? > > 1) Download if tar-file > (http://www.freedesktop.org/software/systemd/man/machinectl.html#Examples) > > # machinectl pull-tar > https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz > > Pulling > 'https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz', > saving as 'trusty-server-cloudimg-amd64-root'. > Downloading 1.7K for > https://cloud-images.ubuntu.com/trusty/current/SHA256SUMS. > Image already downloaded. Skipping download. > Download of > https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz > complete. > Download of https://cloud-images.ubuntu.com/trusty/current/SHA256SUMS > complete. > Downloading 836B for > https://cloud-images.ubuntu.com/trusty/current/SHA256SUMS.gpg. > Download of https://cloud-images.ubuntu.com/trusty/current/SHA256SUMS.gpg > complete. > Failed to create local image: Is a directory Well, the current code assumes btrfs is in use, and will create subvolumes for everything which fails. We probably can add fallbacks for this case to use normal directories for the "pull-tar" case though. The thing is simply that a lot of operations are dead cheap on btrfs, but really expensive on non-btrfs. For example, cloning a directory tree or copying a file is super-cheap on btrfs. > It fails with "Failed to make btrfs subvolume /var/lib/machines/.#.dkr-5... > Inappropriate ioctl for device". Similar here. Note that the dkr code is unlikely to ever support non-btrfs backing file systems, simply because we need cloning of the container directory tree to put it together. My plan is to implicitly add a loopback btrfs filesystem that is automatically made use of if /var/lib/machines is on ext4. Because btrfs actually has sane APIs we can easily set that up and grow it on demand, so that people won't even notice... 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] Looping too fast. Throttling execution a little
On Wed, 18.02.15 10:41, Thierry Parmentelat (thierry.parmente...@inria.fr)
wrote:
> root@bigjohn /vservers # journalctl -b -f
> -- Logs begin at Fri 2014-09-05 04:28:57 CEST. --
> Feb 18 10:38:25 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
> Throttling execution a little.
> Feb 18 10:38:26 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
> Throttling execution a little.
> Feb 18 10:38:28 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
> Throttling execution a little.
> Feb 18 10:38:30 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
> Throttling execution a little.
> Feb 18 10:38:31 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
> Throttling execution a little.
> Feb 18 10:38:33 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
> Throttling execution a little.
THis is happens if for some reason the event loop entered a busy
loop. It's simply a protection against eating up all CPU forever. It's
a symptom of another bug, which is the one to track down.
> # strace -p 1
> <…>
> recvmsg(42, 0x7fff3ea64d00, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1
> EAGAIN (Resource temporarily unavailable)
> timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={0, 1}},
> NULL) = 0
> epoll_wait(4, {{EPOLLIN, {u32=3, u64=3}}}, 36, 0) = 1
> clock_gettime(CLOCK_BOOTTIME, {1959524, 957887776}) = 0
> read(3, "\1\0\0\0\0\0\0\0", 8) = 8
> recvmsg(42, 0x7fff3ea64d00, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1
> EAGAIN (Resource temporarily unavailable)
> timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={0, 1}},
> NULL) = 0
> epoll_wait(4, {{EPOLLIN, {u32=3, u64=3}}}, 36, 0) = 1
> clock_gettime(CLOCK_BOOTTIME, {1959524, 958282696}) = 0
> read(3, "\1\0\0\0\0\0\0\0", 8) = 8
> recvmsg(42, 0x7fff3ea64d00, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1
> EAGAIN (Resource temporarily unavailable)
> timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={0, 1}},
> NULL) = 0
> epoll_wait(4, {{EPOLLIN, {u32=3, u64=3}}}, 36, 0) = 1
> clock_gettime(CLOCK_BOOTTIME, {1959524, 958617432}) = 0
> ^CProcess 1 detached
Hmm, this appears to be caused by a timer that is not reset. First the
timer fd is set to the earliest possible trigger, then epoll_wait() is
entered, which immediately quites. Then the tiemrfd elapse counter is
read which is 1.
It would be interesting to figure out which timer this is.
To make this work, can you reproduce the issue, then use gdb:
1. Type "gdb" to start it
2. Type "attach 1" to attach to PID 1
3. Type "b source_dispatch" to set a break point on the source_dispatch function
4. Type "c" to continue execution
5. This should then break on the next execution of the source_dispatch function
6. This should happen immediately, after all PID 1 is busy looping
around a timer. Use "p s->description" to get a short description
string for the event that is being dispatched. In fact, please use
"p *s" to get all data about the event, and paste it here.
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] [ANNOUNCE] systemd 219
Hi Lennart On 2015-02-18 11:19, Lennart Poettering wrote: > On Wed, 18.02.15 12:13, Joonas Sarajärvi (m...@iki.fi) wrote: > > > FS_NOCOW does no effect btrfs raid settings. If you want this kind of > data redundancy then it will continue to be available even though we > set FS_NOCOW now. Whitout checksum, BTRFS was unable to restore a good copy: in case of RAID1 a flip of a bit makes the two copies different. Only the checksum allows to detected which is the good copy. This was already discussed in the thread (see the answers of Zygo and Chris Murhpy other than the my one) http://www.spinics.net/lists/linux-btrfs/msg41024.html > > Lennart > Goffredo -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] core: emit changes for NFailedUnits property
From: Lucas De Marchi
By notifying the clients when this property is changed it's possible to
allow "system health monitor" tools to get transitions like
running<->degraded. This is an alternative to send changes on the
SystemState property since the latter is more difficult to derive.
---
src/core/dbus-manager.c | 20 +++-
src/core/dbus-manager.h | 1 +
src/core/manager.c | 17 +
src/core/manager.h | 2 ++
src/core/unit.c | 7 ++-
5 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 8ba665d..5e83afb 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -1949,7 +1949,7 @@ const sd_bus_vtable bus_manager_vtable[] = {
SD_BUS_WRITABLE_PROPERTY("LogLevel", "s", property_get_log_level,
property_set_log_level, 0, 0),
SD_BUS_WRITABLE_PROPERTY("LogTarget", "s", property_get_log_target,
property_set_log_target, 0, 0),
SD_BUS_PROPERTY("NNames", "u", property_get_n_names, 0, 0),
-SD_BUS_PROPERTY("NFailedUnits", "u", property_get_n_failed_units, 0,
0),
+SD_BUS_PROPERTY("NFailedUnits", "u", property_get_n_failed_units, 0,
SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY("NJobs", "u", property_get_n_jobs, 0, 0),
SD_BUS_PROPERTY("NInstalledJobs", "u", bus_property_get_unsigned,
offsetof(Manager, n_installed_jobs), 0),
SD_BUS_PROPERTY("NFailedJobs", "u", bus_property_get_unsigned,
offsetof(Manager, n_failed_jobs), 0),
@@ -2102,5 +2102,23 @@ void bus_manager_send_reloading(Manager *m, bool active)
{
r = bus_foreach_bus(m, NULL, send_reloading, INT_TO_PTR(active));
if (r < 0)
log_debug_errno(r, "Failed to send reloading signal: %m");
+}
+
+static int send_changed_signal(sd_bus *bus, void *userdata) {
+assert(bus);
+
+return sd_bus_emit_properties_changed_strv(bus,
+ "/org/freedesktop/systemd1",
+
"org.freedesktop.systemd1.Manager",
+ NULL);
+}
+void bus_manager_send_change_signal(Manager *m) {
+int r;
+
+assert(m);
+
+r = bus_foreach_bus(m, NULL, send_changed_signal, NULL);
+if (r < 0)
+log_debug_errno(r, "Failed to send manager change signal: %m");
}
diff --git a/src/core/dbus-manager.h b/src/core/dbus-manager.h
index e1903fa..3f7cfef 100644
--- a/src/core/dbus-manager.h
+++ b/src/core/dbus-manager.h
@@ -28,3 +28,4 @@ extern const sd_bus_vtable bus_manager_vtable[];
void bus_manager_send_finished(Manager *m, usec_t firmware_usec, usec_t
loader_usec, usec_t kernel_usec, usec_t initrd_usec, usec_t userspace_usec,
usec_t total_usec);
void bus_manager_send_reloading(Manager *m, bool active);
+void bus_manager_send_change_signal(Manager *m);
diff --git a/src/core/manager.c b/src/core/manager.c
index 4775219..0e9e154 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -3061,6 +3061,23 @@ const char *manager_get_runtime_prefix(Manager *m) {
getenv("XDG_RUNTIME_DIR");
}
+void manager_update_failed_units(Manager *m, Unit *u, bool failed) {
+unsigned size;
+
+assert(m);
+assert(u->manager == m);
+
+size = set_size(m->failed_units);
+
+if (failed)
+set_put(m->failed_units, u);
+else
+set_remove(m->failed_units, u);
+
+if (set_size(m->failed_units) != size)
+bus_manager_send_change_signal(m);
+}
+
ManagerState manager_state(Manager *m) {
Unit *u;
diff --git a/src/core/manager.h b/src/core/manager.h
index d3971f1..418b752 100644
--- a/src/core/manager.h
+++ b/src/core/manager.h
@@ -367,5 +367,7 @@ const char *manager_get_runtime_prefix(Manager *m);
ManagerState manager_state(Manager *m);
+void manager_update_failed_units(Manager *m, Unit *u, bool failed);
+
const char *manager_state_to_string(ManagerState m) _const_;
ManagerState manager_state_from_string(const char *s) _pure_;
diff --git a/src/core/unit.c b/src/core/unit.c
index ee8e607..ec45ec9 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -522,7 +522,7 @@ void unit_free(Unit *u) {
free(u->cgroup_path);
}
-set_remove(u->manager->failed_units, u);
+manager_update_failed_units(u->manager, u, false);
set_remove(u->manager->startup_units, u);
free(u->description);
@@ -1801,10 +1801,7 @@ void unit_notify(Unit *u, UnitActiveState os,
UnitActiveState ns, bool reload_su
}
/* Keep track of failed units */
-if (ns == UNIT_FAILED)
-set_put(u->manager->failed_units, u);
-else
-set_remove(u->manager->failed_units, u);
+manager_update_failed_units(u->manager, u, ns == UNIT_FAILED);
/* Make sure the cgroup is always rem
Re: [systemd-devel] [PATCH 1/9] fsckd daemon for inter-fsckd communication
Le 18/02/2015 17:00, Martin Pitt a écrit : Ça va Didier, these now apply/build/check fine against master, I tested the binaries on my laptop and in a VM, all review comments were addressed. As discussed with Zbigniew on IRC I landed them now. Thanks a lot Martin for doing this further testing and reviews! A big omission is of course the lack of German translations! :-) (I'll commit them now) You didn't want me to try to add those translations, believe me ;) Danke schön. Didier ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/9] fsckd daemon for inter-fsckd communication
Ça va Didier, these now apply/build/check fine against master, I tested the binaries on my laptop and in a VM, all review comments were addressed. As discussed with Zbigniew on IRC I landed them now. A big omission is of course the lack of German translations! :-) (I'll commit them now) Merci, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tmpfiles.d specifier support on "argument" when operating on files
El 18/02/15 a las 07:10, Lennart Poettering escribió: On Tue, 17.02.15 17:35, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: Please fix this for all arguments, not just symlinks. Thanks for taking a look, I will post a complete version later. ;) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shared: fix utf16_to_utf8() on big endian machines
On Wed, Feb 18, 2015 at 3:19 PM, Martin Pitt wrote: > Martin Pitt [2015-02-18 15:06 +0100]: >> I couldn't quickly find a reference for EFI variables (which is the >> main thing we are using this for), and I don't have/know a big-endian >> EFI machine to check this on. > > I had a look into the official spec > http://www.uefi.org/sites/default/files/resources/UEFI_2.4.pdf > > While it defines the encoding of strings in several places, like in > "28.2.6 Strings" (page 1542), it only says that it uses the UCS-2 > subset of UTF-16. UCS-2 is defined to be big-endian only, but > wikipedia says that in practice a lot of implementations use > little-endian. > > "little-endian" and "big-endian" have no useful hits, and "UTF-16LE" > and "UTF-16BE" have no hits in the document. > > On my x86_64 laptop it quite clearly uses little-endian, and the > variables don't seem to have a BOM marker at the start to indicate > endianness. > >> So if EFI variables are defined to be UTF16LE always, your patch is >> correct. > > So meh -- is this defined at all? Defined or not, it appears to be LE in practice, we didn't get any bug reports, and there does not seem to be any way to detect LE/BE, so I think we are best of leaving it alone and revisit the problem if any hardware has any issues (not that I see how we can work around it). -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shared: fix utf16_to_utf8() on big endian machines
Martin Pitt [2015-02-18 15:06 +0100]: > I couldn't quickly find a reference for EFI variables (which is the > main thing we are using this for), and I don't have/know a big-endian > EFI machine to check this on. I had a look into the official spec http://www.uefi.org/sites/default/files/resources/UEFI_2.4.pdf While it defines the encoding of strings in several places, like in "28.2.6 Strings" (page 1542), it only says that it uses the UCS-2 subset of UTF-16. UCS-2 is defined to be big-endian only, but wikipedia says that in practice a lot of implementations use little-endian. "little-endian" and "big-endian" have no useful hits, and "UTF-16LE" and "UTF-16BE" have no hits in the document. On my x86_64 laptop it quite clearly uses little-endian, and the variables don't seem to have a BOM marker at the start to indicate endianness. > So if EFI variables are defined to be UTF16LE always, your patch is > correct. So meh -- is this defined at all? Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 219
Dnia wtorek, 17 lutego 2015 17:23:55 Lennart Poettering pisze: > On Tue, 17.02.15 17:13, Maciej Wereski (m.were...@partner.samsung.com) wrote: > > Hello, > > > > Dnia poniedziałek, 16 lutego 2015 23:59:56 Lennart Poettering pisze: > > > 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. > > > > I was able to build systemd v219 both on armv7l and aarch64. As a > > workaround I had to disable Link Time Optimizations. > > Well, did it segfault for you if you had lto on? > > This toolchain bug is tracked here btw: > > https://bugzilla.redhat.com/show_bug.cgi?id=1193212 No, we have some issues rather specific to our buildsystem. -- Maciej Wereski Samsung R&D Institute Poland Samsung Electronics m.were...@partner.samsung.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 219
On Wed, Feb 18, 2015 at 11:03:39AM +0100, Lennart Poettering wrote: > Well it's the only logic that can work really, already since the same > device node is usually known to the kernel by a different name thatn > to userspace. Trying to always map that is really nasty, as one can > see with the GPT generator complexity. > > > Wouldn't it be better if there was some other state - e.g. "conflict" if > > something other than the desired device was mounted to the specified > > destination? > > I think it's really safe not to consider that a problem. Yes, especially that the administator must take explicit manual actions to reach this state. They should remember that they did that. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shared: fix utf16_to_utf8() on big endian machines
On Wed, Feb 18, 2015 at 3:06 PM, Martin Pitt wrote: > Hey Tom, > > Tom Gundersen [2015-02-18 14:34 +0100]: >> I think we want to assume that we only get UTF-16LE, so it looks like >> it is the test that is buggy. That's what we agreed, right Lennart? > > Ah, ok. Indeed GUID partition names are UTF16LE. > > I couldn't quickly find a reference for EFI variables (which is the > main thing we are using this for), and I don't have/know a big-endian > EFI machine to check this on. I found > > http://uefi.blogspot.de/2009/12/uefi-hii-part-7-character-encoding.html > > which raises the endianness question (but doesn't answer it), and > https://en.wikipedia.org/wiki/UTF-16 says both LE and BE are possible. > >> How about the attached patch? > > Confirmed to work on powerpc (BE) and x86_64 (LE). So if EFI variables > are defined to be UTF16LE always, your patch is correct. Thanks. Maybe Kay or Harald want to comment on the EFI question? For JSON (the other use), we are always requiring LE (BE is possible, but we'll detect that and refuse to load the file). For now I'll push this patch as it confirms the test to be in line with the code. If we need to add BE support we should do that separately I guess. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shared: fix utf16_to_utf8() on big endian machines
Hey Tom, Tom Gundersen [2015-02-18 14:34 +0100]: > I think we want to assume that we only get UTF-16LE, so it looks like > it is the test that is buggy. That's what we agreed, right Lennart? Ah, ok. Indeed GUID partition names are UTF16LE. I couldn't quickly find a reference for EFI variables (which is the main thing we are using this for), and I don't have/know a big-endian EFI machine to check this on. I found http://uefi.blogspot.de/2009/12/uefi-hii-part-7-character-encoding.html which raises the endianness question (but doesn't answer it), and https://en.wikipedia.org/wiki/UTF-16 says both LE and BE are possible. > How about the attached patch? Confirmed to work on powerpc (BE) and x86_64 (LE). So if EFI variables are defined to be UTF16LE always, your patch is correct. Thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shared: fix utf16_to_utf8() on big endian machines
On Wed, Feb 18, 2015 at 6:54 AM, Martin Pitt wrote:
> 219 shows a test failure in test-utf8 on big-endian machines (on
> Debian: powerpc, s390, mips):
>
> Assertion 'streq(a, utf8)' failed at src/test/test-utf8.c:103, function
> test_utf16_to_utf8(). Aborting.
>
> gdb shows that indeed the converted string is utter bogus. a is the
> converted string, utf8 the expected outcome:
>
> | Program received signal SIGABRT, Aborted.
> | 0x20319c48 in raise () from /lib/powerpc-linux-gnu/libc.so.6
> | (gdb) f 3
> | #3 0x204befbc in test_utf16_to_utf8 () at src/test/test-utf8.c:103
> | 103 assert_se(streq(a, utf8));
> | (gdb) p a
> | $1 = 0x204eb068
> "\346\204\200\303\230\346\210\200\303\234\346\214\200\307\230\343\237\234"
> | (gdb) p utf8
> | $2 = "abc\360\220\220\267"
>
> Patch against master attached, tested on both little-endian (unchanged
> behaviour/code) and big-endian machine.
>
> CC'ing Tom for reviewing, as that was introduced in
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=04166cb7d and
> he might still have the UTF-16 stuff in his head :-)
I think we want to assume that we only get UTF-16LE, so it looks like
it is the test that is buggy. That's what we agreed, right Lennart?
How about the attached patch?
Cheers,
Tom
From 20979aaab29e4cc021fa937df8f92ea1694a7d0a Mon Sep 17 00:00:00 2001
From: Tom Gundersen
Date: Wed, 18 Feb 2015 14:33:50 +0100
Subject: [PATCH] test: utf8 - fix utf16 tests on BE machines
---
src/test/test-utf8.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/test/test-utf8.c b/src/test/test-utf8.c
index befa385..346f852 100644
--- a/src/test/test-utf8.c
+++ b/src/test/test-utf8.c
@@ -95,7 +95,7 @@ static void test_utf8_escaping_printable(void) {
static void test_utf16_to_utf8(void) {
char *a = NULL;
-const uint16_t utf16[] = { 'a', 0xd800, 'b', 0xdc00, 'c', 0xd801, 0xdc37 };
+const uint16_t utf16[] = { htole16('a'), htole16(0xd800), htole16('b'), htole16(0xdc00), htole16('c'), htole16(0xd801), htole16(0xdc37) };
const char utf8[] = { 'a', 'b', 'c', 0xf0, 0x90, 0x90, 0xb7, 0 };
a = utf16_to_utf8(utf16, 14);
--
2.3.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Cgroup limits for user processes
What is the best way to set cgroup limits for user processes? I mean the individual processes. I know that you can set limits for user.slice, but how to set limits for, let's say, firefox? I tried to make a service file for firefox, it looks like this: [Unit] Description=Firefox Web Browser Documentation=https://www.mozilla.org/ After=graphical.target Before=shutdown.target [Service] Environment="DISPLAY=:0" User=morfik Type=simple ExecStart=/opt/firefox/firefox -new-instance -ProfileManager Restart=no RemainAfterExit=no Nice=5 IOSchedulingClass=best-effort IOSchedulingPriority=3 OOMScoreAdjust=500 CPUShares=512 MemoryLimit=300M BlockIOWeight=256 The parameters are just for testing purposes, and of course the unit is a system unit. I tested it with: morfik:~$ systemctl start firefox.service AUTHENTICATING FOR org.freedesktop.systemd1.manage-units === Authentication is required to manage system services or units. Authenticating as: morfik Password: AUTHENTICATION COMPLETE === and the service starts. The "nice" parameters are set, so are the cgroups: morfik:~$ systemctl status firefox ● firefox.service - Firefox Web Browser Loaded: loaded (/etc/systemd/system/firefox.service; static; vendor preset: enabled) Active: active (running) since Wed 2015-02-18 12:11:49 CET; 1min 46s ago Docs: https://www.mozilla.org/ Main PID: 60773 (firefox) Memory: 259.2M (limit: 300.0M) CGroup: /system.slice/firefox.service └─60773 /opt/firefox/firefox -new-instance -ProfileManager I didn't really like the way I stared the firefox, so I tried to move the service from the system to the user dir. I also changed a little bit the unit file -- the user and env lines were removed. After the change, I started the service in order to test whether it works or not: morfik:~$ systemctl --user daemon-reload morfik:~$ systemctl --user start firefox.service morfik:~$ systemctl --user status firefox.service ● firefox.service - Firefox Web Browser Loaded: loaded (/etc/systemd/user/firefox.service; static; vendor preset: enabled) Active: active (running) since Wed 2015-02-18 12:20:56 CET; 19s ago Docs: https://www.mozilla.org/ Main PID: 64082 (firefox) CGroup: /user.slice/user-1000.slice/user@1000.service/firefox.service └─64082 /opt/firefox/firefox -new-instance -ProfileManager It works, but as you can see, there's no cgroup limits. The "nice" parameters are set correctly, but it looks like the cgroup ones are ignored for some reason. Here are some additional commands: # cat /proc/`pidof firefox`/cgroup 9:blkio:/ 8:cpuset:/ 7:freezer:/ 6:cpu,cpuacct:/ 5:perf_event:/ 4:devices:/user.slice 3:memory:/ 2:net_cls,net_prio:/ 1:name=systemd:/user.slice/user-1000.slice/user@1000.service/firefox.service root:~# systemd-cgls ├─1 /sbin/init splash ├─system.slice │ ├─dbus.service │ │ └─1529 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation ... └─user.slice ├─user-1000.slice │ ├─session-1.scope │ │ ├─ 2027 lightdm --session-child 12 19 ... │ └─user@1000.service │ ├─2031 /lib/systemd/systemd --user │ ├─2032 (sd-pam) │ └─firefox.service │ └─64082 /opt/firefox/firefox -new-instance -ProfileManager └─user-108.slice ├─session-c1.scope │ ├─2013 /usr/bin/dbus-launch --autolaunch 159815709bbc46c29ef786cfc497afd4 --binary-syntax --close-stderr │ ├─2014 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session │ ├─2016 /usr/lib/at-spi2-core/at-spi-bus-launcher │ ├─2020 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3 │ └─2023 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session └─user@108.service ├─1992 /lib/systemd/systemd --user └─1993 (sd-pam) root:~# ls -al /sys/fs/cgroup/systemd/user.slice/user-1000.slice/user@1000.service/firefox.service/ total 0 drwxr-xr-x 2 morfik morfik 0 2015-02-18 12:20:56 ./ drwxr-xr-x 24 morfik morfik 0 2015-02-18 12:20:56 ../ -rw-r--r-- 1 morfik morfik 0 2015-02-18 12:20:56 cgroup.clone_children -rw-r--r-- 1 morfik morfik 0 2015-02-18 12:20:56 cgroup.procs -rw-r--r-- 1 morfik morfik 0 2015-02-18 12:20:56 notify_on_release -rw-r--r-- 1 morfik morfik 0 2015-02-18 12:20:56 tasks BTW, one more thing. Is there a way to set a mark for network packets using unit services? I really need this feature, but I couldn't find any useful information on this subject. pgpEAfAZxmQeG.pgp Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 9/9] Add mock fsck process
>From 59d7202a3755dd73ebad94a20921975330a4ee83 Mon Sep 17 00:00:00 2001
From: Didier Roche
Date: Mon, 26 Jan 2015 17:46:36 +0100
Subject: [PATCH 9/9] Add mock fsck process
---
test/mocks/fsck | 27 +++
1 file changed, 27 insertions(+)
create mode 100755 test/mocks/fsck
diff --git a/test/mocks/fsck b/test/mocks/fsck
new file mode 100755
index 000..77b50d7
--- /dev/null
+++ b/test/mocks/fsck
@@ -0,0 +1,27 @@
+#!/bin/bash
+fd=0
+
+OPTIND=1
+while getopts "C:aTlM" opt; do
+case "$opt" in
+C)
+fd=$OPTARG
+;;
+\?);;
+esac
+done
+
+shift "$((OPTIND-1))"
+device=$1
+
+echo "Running fake fsck on $device"
+
+declare -a maxpass=(30 5 2 30 60)
+
+for pass in {1..5}; do
+maxprogress=${maxpass[$((pass-1))]}
+for (( current=0; current<=${maxprogress}; current++)); do
+echo "$pass $current $maxprogress $device">&$fd
+sleep 0.1
+done
+done
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 8/9] Add man page and references to it.
>From 9db0d5cd0cc20b899ddf77ccdfcbe214978eb463 Mon Sep 17 00:00:00 2001 From: Didier Roche Date: Mon, 26 Jan 2015 17:34:59 +0100 Subject: [PATCH 8/9] Add man page and references to it. Add man page explaining the plymouth theme protocol, usage of the daemon as well as the socket activation part. Adapt existing fsck man page. --- Makefile-man.am| 12 +++ man/systemd-f...@.service.xml | 26 +++ man/systemd-fsckd.service.xml | 162 + units/systemd-fsckd.service.in | 1 + units/systemd-fsckd.socket | 2 +- 5 files changed, 189 insertions(+), 14 deletions(-) create mode 100644 man/systemd-fsckd.service.xml diff --git a/Makefile-man.am b/Makefile-man.am index d0fb9aa..7a9612e 100644 --- a/Makefile-man.am +++ b/Makefile-man.am @@ -66,6 +66,7 @@ MANPAGES += \ man/systemd-efi-boot-generator.8 \ man/systemd-escape.1 \ man/systemd-fsck@.service.8 \ + man/systemd-fsckd.service.8 \ man/systemd-fstab-generator.8 \ man/systemd-getty-generator.8 \ man/systemd-gpt-auto-generator.8 \ @@ -209,6 +210,8 @@ MANPAGES_ALIAS += \ man/systemd-ask-password-wall.service.8 \ man/systemd-fsck-root.service.8 \ man/systemd-fsck.8 \ + man/systemd-fsckd.8 \ + man/systemd-fsckd.socket.8 \ man/systemd-hibernate-resume.8 \ man/systemd-hibernate.service.8 \ man/systemd-hybrid-sleep.service.8 \ @@ -321,6 +324,8 @@ man/systemd-ask-password-wall.path.8: man/systemd-ask-password-console.service.8 man/systemd-ask-password-wall.service.8: man/systemd-ask-password-console.service.8 man/systemd-fsck-root.service.8: man/systemd-fsck@.service.8 man/systemd-fsck.8: man/systemd-fsck@.service.8 +man/systemd-fsckd.8: man/systemd-fsckd.service.8 +man/systemd-fsckd.socket.8: man/systemd-fsckd.service.8 man/systemd-hibernate-resume.8: man/systemd-hibernate-resume@.service.8 man/systemd-hibernate.service.8: man/systemd-suspend.service.8 man/systemd-hybrid-sleep.service.8: man/systemd-suspend.service.8 @@ -601,6 +606,12 @@ man/systemd-fsck-root.service.html: man/systemd-f...@.service.html man/systemd-fsck.html: man/systemd-f...@.service.html $(html-alias) +man/systemd-fsckd.html: man/systemd-fsckd.service.html + $(html-alias) + +man/systemd-fsckd.socket.html: man/systemd-fsckd.service.html + $(html-alias) + man/systemd-hibernate-resume.html: man/systemd-hibernate-res...@.service.html $(html-alias) @@ -1738,6 +1749,7 @@ EXTRA_DIST += \ man/systemd-escape.xml \ man/systemd-firstboot.xml \ man/systemd-f...@.service.xml \ + man/systemd-fsckd.service.xml \ man/systemd-fstab-generator.xml \ man/systemd-getty-generator.xml \ man/systemd-gpt-auto-generator.xml \ diff --git a/man/systemd-f...@.service.xml b/man/systemd-f...@.service.xml index 88e11e8..69b8fdd 100644 --- a/man/systemd-f...@.service.xml +++ b/man/systemd-f...@.service.xml @@ -81,10 +81,10 @@ last check, number of mounts, unclean unmount, etc. systemd-fsck will forward file system -checking progress to the console. If a file system check fails for -a service without nofail, emergency mode is -activated, by isolating to -emergency.target. +checking progress to systemd-fsckd.service +socket. If a file system check fails for a service without +nofail, emergency mode is activated, by isolating +to emergency.target. @@ -125,16 +125,16 @@ See Also systemd1, - fsck8, + fsck8, systemd-quotacheck.service8, - fsck.btrfs8, - fsck.cramfs8, - fsck.ext48, - fsck.fat8, - fsck.hfsplus8, - fsck.minix8, - fsck.ntfs8, - fsck.xfs8 + fsck.btrfs8, + fsck.cramfs8, + fsck.ext48, + fsck.fat8, + fsck.hfsplus8, + fsck.minix8, + fsck.ntfs8, + fsck.xfs8 diff --git a/man/systemd-fsckd.service.xml b/man/systemd-fsckd.service.xml new file mode 100644 index 000..2ad7844 --- /dev/null +++ b/man/systemd-fsckd.service.xml @@ -0,0 +1,162 @@ + + +http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";> + +http://www.w3.org/2001/XInclude";> + + +systemd-fsckd.service +systemd + + + +Developer +Didier +Roche +didro...@ubuntu.com + + + + + +systemd-fsckd.service +8 + + + +systemd-fsckd.service +systemd-fsckd.socket +systemd-fsckd +File system check progress reporting + + + +systemd-fsckd.service +systemd-fsckd.socket +/usr/lib/systemd/systemd-fsckd + + + +Description + +systemd-fsckd.service is a service responsible +for receiving file system check progress, and communicating some +consolidated data to console and plymouth (if running). It also handles +possible check cancellations. + +systemd-fsckd receives messages about file +system check progress from systemd-fsck through a +UNIX domain socket. It can display the progress of the least advanced +fsck as well as the total number of devic
Re: [systemd-devel] [PATCH 6/9] Refresh po files
>From 03f05550e81941d2073d151aaedfe3d06c1f95b0 Mon Sep 17 00:00:00 2001 From: Didier Roche Date: Mon, 26 Jan 2015 17:23:08 +0100 Subject: [PATCH 6/9] Refresh po files Also, add new plymouth fsckd translated strings in french. Refreshed with "make update-po". --- po/de.po| 11 +++ po/el.po| 11 +++ po/fr.po| 11 +++ po/hu.po| 11 +++ po/it.po| 11 +++ po/pl.po| 11 +++ po/pt_BR.po | 11 +++ po/ru.po| 11 +++ po/sv.po| 11 +++ po/uk.po| 12 10 files changed, 111 insertions(+) diff --git a/po/de.po b/po/de.po index 69c1fb9..0f87024 100644 --- a/po/de.po +++ b/po/de.po @@ -454,5 +454,16 @@ msgstr "" "Legitimierung ist zum Festlegen, ob Netzwerkzeitabgeich eingeschaltet sein " "soll, erforderlich." +#: ../src/fsckd/fsckd.c:186 +msgid "Press Ctrl+C to cancel all filesystem checks in progress" +msgstr "" + +#: ../src/fsckd/fsckd.c:227 +#, c-format +msgid "Checking in progress on %d disk (%3.1f%% complete)" +msgid_plural "Checking in progress on %d disks (%3.1f%% complete)" +msgstr[0] "" +msgstr[1] "" + #~ msgid "Privileged system and service manager access" #~ msgstr "Privilegierter Zugriff auf die System- und Dienstverwaltung" diff --git a/po/el.po b/po/el.po index 8f7a0ed..14ee497 100644 --- a/po/el.po +++ b/po/el.po @@ -402,3 +402,14 @@ msgid "Authentication is required to access the system and service manager." msgstr "" "ÎÏαιÏείÏαι ÏιÏÏοÏοίηÏη για να ÏÏοÏÏελάÏεÏε Ïον διαÏειÏιÏÏή ÏÏ ÏÏήμαÏÎ¿Ï ÎºÎ±Î¹ " "Ï ÏηÏεÏιÏν." + +#: ../src/fsckd/fsckd.c:186 +msgid "Press Ctrl+C to cancel all filesystem checks in progress" +msgstr "" + +#: ../src/fsckd/fsckd.c:227 +#, c-format +msgid "Checking in progress on %d disk (%3.1f%% complete)" +msgid_plural "Checking in progress on %d disks (%3.1f%% complete)" +msgstr[0] "" +msgstr[1] "" diff --git a/po/fr.po b/po/fr.po index 4d4fc6b..8e44e0c 100644 --- a/po/fr.po +++ b/po/fr.po @@ -433,3 +433,14 @@ msgid "" msgstr "" "Authentification requise pour activer ou désactiver la synchronisation de " "l'heure avec le réseau." + +#: ../src/fsckd/fsckd.c:186 +msgid "Press Ctrl+C to cancel all filesystem checks in progress" +msgstr "Appuyez sur Ctrl+C pour annuler toutes vérifications du système de fichier en cours" + +#: ../src/fsckd/fsckd.c:227 +#, c-format +msgid "Checking in progress on %d disk (%3.1f%% complete)" +msgid_plural "Checking in progress on %d disks (%3.1f%% complete)" +msgstr[0] "Vérification en cours sur %d disque (%3.1f%% complété)" +msgstr[1] "Vérification en cours sur %d disques (%3.1f%% complété)" diff --git a/po/hu.po b/po/hu.po index a914b3c..308e03d 100644 --- a/po/hu.po +++ b/po/hu.po @@ -411,3 +411,14 @@ msgstr "A systemd állapotának újratöltése" #: ../src/core/org.freedesktop.systemd1.policy.in.in.h:8 msgid "Authentication is required to reload the systemd state." msgstr "HitelesÃtés szükséges a systemd állapotának újratöltéséhez." + +#: ../src/fsckd/fsckd.c:186 +msgid "Press Ctrl+C to cancel all filesystem checks in progress" +msgstr "" + +#: ../src/fsckd/fsckd.c:227 +#, c-format +msgid "Checking in progress on %d disk (%3.1f%% complete)" +msgid_plural "Checking in progress on %d disks (%3.1f%% complete)" +msgstr[0] "" +msgstr[1] "" diff --git a/po/it.po b/po/it.po index 93a1e79..53cccfe 100644 --- a/po/it.po +++ b/po/it.po @@ -424,3 +424,14 @@ msgstr "Autenticazione richiesta per riavviare lo stato di sistemd." #~ msgid "Privileged system and service manager access" #~ msgstr "Accesso privilegiato per la gestione del sistema e dei servizi" + +#: ../src/fsckd/fsckd.c:186 +msgid "Press Ctrl+C to cancel all filesystem checks in progress" +msgstr "" + +#: ../src/fsckd/fsckd.c:227 +#, c-format +msgid "Checking in progress on %d disk (%3.1f%% complete)" +msgid_plural "Checking in progress on %d disks (%3.1f%% complete)" +msgstr[0] "" +msgstr[1] "" diff --git a/po/pl.po b/po/pl.po index e5987be..cd7dbda 100644 --- a/po/pl.po +++ b/po/pl.po @@ -411,3 +411,14 @@ msgid "" msgstr "" "Wymagane jest uwierzytelnienie, aby kontrolowaÄ, czy wÅÄ czyÄ synchronizacjÄ " "czasu przez sieÄ." + +#: ../src/fsckd/fsckd.c:186 +msgid "Press Ctrl+C to cancel all filesystem checks in progress" +msgstr "" + +#: ../src/fsckd/fsckd.c:227 +#, c-format +msgid "Checking in progress on %d disk (%3.1f%% complete)" +msgid_plural "Checking in progress on %d disks (%3.1f%% complete)" +msgstr[0] "" +msgstr[1] "" diff --git a/po/pt_BR.po b/po/pt_BR.po index 5204047..072b8d3 100644 --- a/po/pt_BR.po +++ b/po/pt_BR.po @@ -419,3 +419,14 @@ msgstr "à necessária autenticação para recarregar o estado do sistema." #~ msgid "Privileged system and service manager access" #~ msgstr "Acesso privilegiado ao gerenciador de serviço e de sistema" + +#: ../src/fsckd/fsckd.c:186 +msgid "Press Ctrl+C to cancel all filesystem checks in progress" +msgstr "" + +#: ../src
Re: [systemd-devel] [PATCH 5/9] Translate fsckd messages for plymouth
>From 3f029b3549b736f57cfb73c016022f13185187f8 Mon Sep 17 00:00:00 2001
From: Didier Roche
Date: Mon, 26 Jan 2015 17:12:54 +0100
Subject: [PATCH 5/9] Translate fsckd messages for plymouth
For plymouth themes not supporting i18n (like .script), send translated
messages to display to user, which is equivalent to the sent machine
readable data.
---
po/POTFILES.in| 1 +
src/fsckd/fsckd.c | 10 +++---
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/po/POTFILES.in b/po/POTFILES.in
index b4c1121..70e7594 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -5,3 +5,4 @@ src/locale/org.freedesktop.locale1.policy.in
src/login/org.freedesktop.login1.policy.in
src/machine/org.freedesktop.machine1.policy.in
src/timedate/org.freedesktop.timedate1.policy.in
+src/fsckd/fsckd.c
diff --git a/src/fsckd/fsckd.c b/src/fsckd/fsckd.c
index dc00fc6..834476c 100644
--- a/src/fsckd/fsckd.c
+++ b/src/fsckd/fsckd.c
@@ -24,6 +24,7 @@
#include
#include
+#include
#include
#include
#include
@@ -182,7 +183,7 @@ static int send_message_plymouth(Manager *m, const char *message) {
if (r < 0)
return log_warning_errno(errno, "Can't send to plymouth cancel key: %m");
m->plymouth_cancel_sent = true;
-plymouth_cancel_message = strjoina("fsckd-cancel-msg:", "Press Ctrl+C to cancel all filesystem checks in progress");
+plymouth_cancel_message = strjoina("fsckd-cancel-msg:", _("Press Ctrl+C to cancel all filesystem checks in progress"));
r = send_message_plymouth_socket(m->plymouth_fd, plymouth_cancel_message, false);
if (r < 0)
log_warning_errno(r, "Can't send filesystem cancel message to plymouth: %m");
@@ -222,8 +223,10 @@ static int update_global_progress(Manager *m) {
m->numdevices = current_numdevices;
m->percent = current_percent;
-if (asprintf(&console_message, "Checking in progress on %d disks (%3.1f%% complete)",
-m->numdevices, m->percent) < 0)
+if (asprintf(&console_message,
+ ngettext("Checking in progress on %d disk (%3.1f%% complete)",
+ "Checking in progress on %d disks (%3.1f%% complete)", m->numdevices),
+ m->numdevices, m->percent) < 0)
return -ENOMEM;
if (asprintf(&fsck_message, "fsckd:%d:%3.1f:%s", m->numdevices, m->percent, console_message) < 0)
return -ENOMEM;
@@ -507,6 +510,7 @@ int main(int argc, char *argv[]) {
log_set_target(LOG_TARGET_AUTO);
log_parse_environment();
log_open();
+init_gettext();
r = parse_argv(argc, argv);
if (r <= 0)
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 7/9] Add fsckd service and socket, retarget systemd-fsck
>From 20b16b76f4197604525579cef99c8d6b8b5484e5 Mon Sep 17 00:00:00 2001 From: Didier Roche Date: Mon, 26 Jan 2015 17:30:00 +0100 Subject: [PATCH 7/9] Add fsckd service and socket, retarget systemd-fsck systemd-fsckd can be socket-activated by systemd-fsck process. Reflect that in the different unit files. --- Makefile.am| 3 +++ units/.gitignore | 1 + units/systemd-fsck-root.service.in | 3 ++- units/systemd-f...@.service.in | 4 ++-- units/systemd-fsckd.service.in | 16 units/systemd-fsckd.socket | 14 ++ 6 files changed, 38 insertions(+), 3 deletions(-) create mode 100644 units/systemd-fsckd.service.in create mode 100644 units/systemd-fsckd.socket diff --git a/Makefile.am b/Makefile.am index f8c425b..d553339 100644 --- a/Makefile.am +++ b/Makefile.am @@ -494,6 +494,7 @@ dist_systemunit_DATA = \ units/slices.target \ units/system.slice \ units/x-.slice \ + units/systemd-fsckd.socket \ units/systemd-initctl.socket \ units/systemd-shutdownd.socket \ units/syslog.socket \ @@ -545,6 +546,7 @@ nodist_systemunit_DATA = \ units/systemd-kexec.service \ units/systemd-fsck@.service \ units/systemd-fsck-root.service \ + units/systemd-fsckd.service \ units/systemd-machine-id-commit.service \ units/systemd-udevd.service \ units/systemd-udev-trigger.service \ @@ -598,6 +600,7 @@ EXTRA_DIST += \ units/user/systemd-exit.service.in \ units/systemd-f...@.service.in \ units/systemd-fsck-root.service.in \ + units/systemd-fsckd.service.in \ units/systemd-machine-id-commit.service.in \ units/u...@.service.m4.in \ units/debug-shell.service.in \ diff --git a/units/.gitignore b/units/.gitignore index 6fdb629..26ae965 100644 --- a/units/.gitignore +++ b/units/.gitignore @@ -28,6 +28,7 @@ /systemd-firstboot.service /systemd-fsck-root.service /systemd-fsck@.service +/systemd-fsckd.service /systemd-machine-id-commit.service /systemd-halt.service /systemd-hibernate.service diff --git a/units/systemd-fsck-root.service.in b/units/systemd-fsck-root.service.in index 6d76578..f493445 100644 --- a/units/systemd-fsck-root.service.in +++ b/units/systemd-fsck-root.service.in @@ -9,12 +9,13 @@ Description=File System Check on Root Device Documentation=man:systemd-fsck-root.service(8) DefaultDependencies=no +Wants=systemd-fsckd.socket Before=local-fs.target shutdown.target +After=systemd-fsckd.socket ConditionPathIsReadWrite=!/ [Service] Type=oneshot RemainAfterExit=yes ExecStart=@rootlibexecdir@/systemd-fsck -StandardOutput=journal+console TimeoutSec=0 diff --git a/units/systemd-f...@.service.in b/units/systemd-f...@.service.in index 857e625..e6d98c0 100644 --- a/units/systemd-f...@.service.in +++ b/units/systemd-f...@.service.in @@ -10,12 +10,12 @@ Description=File System Check on %f Documentation=man:systemd-fsck@.service(8) DefaultDependencies=no BindsTo=%i.device -After=%i.device systemd-fsck-root.service local-fs-pre.target +Wants=systemd-fsckd.socket +After=%i.device systemd-fsck-root.service local-fs-pre.target systemd-fsckd.socket Before=shutdown.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=@rootlibexecdir@/systemd-fsck %f -StandardOutput=journal+console TimeoutSec=0 diff --git a/units/systemd-fsckd.service.in b/units/systemd-fsckd.service.in new file mode 100644 index 000..27c325f --- /dev/null +++ b/units/systemd-fsckd.service.in @@ -0,0 +1,16 @@ +# This file is part of systemd. +# +# systemd is free software; you can redistribute it and/or modify it +# under the terms of the GNU Lesser General Public License as published by +# the Free Software Foundation; either version 2.1 of the License, or +# (at your option) any later version. + +[Unit] +Description=File System Check Daemon to report status +DefaultDependencies=no +Requires=systemd-fsckd.socket +Before=shutdown.target + +[Service] +ExecStart=@rootlibexecdir@/systemd-fsckd +StandardOutput=journal+console diff --git a/units/systemd-fsckd.socket b/units/systemd-fsckd.socket new file mode 100644 index 000..a8994a1 --- /dev/null +++ b/units/systemd-fsckd.socket @@ -0,0 +1,14 @@ +# This file is part of systemd. +# +# systemd is free software; you can redistribute it and/or modify it +# under the terms of the GNU Lesser General Public License as published by +# the Free Software Foundation; either version 2.1 of the License, or +# (at your option) any later version. + +[Unit] +Description=fsck to fsckd communication Socket +Documentation=man:systemd-fsck@.service(8) man:systemd-fsck-root.service(8) +DefaultDependencies=no + +[Socket] +ListenStream=/run/systemd/fsckd -- 2.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/9] Connect to plymouth and support cancellation of in, progress fsck
Le 18/02/2015 00:30, Zbigniew Jędrzejewski-Szmek a écrit :
On Tue, Feb 17, 2015 at 05:26:05PM +0100, Didier Roche wrote:
+r = send_message_plymouth_socket(m->plymouth_fd,
plymouth_cancel_message, false);
+if (r < 0)
+log_warning_errno(r, "Can't send cancel user message to
plymouth: %m");
+} else if (m->numdevices == 0) {
+m->plymouth_cancel_sent = false;
+r = send_message_plymouth_socket(m->plymouth_fd, "", false);
+if (r < 0)
+log_warning_errno(r, "Can't clear cancel user message to
plymouth: %m");
Not *that* important, but those two log_warning_errnos are poorly worded.
If I was a user, I'd be a bit worried if I saw that somebody tried to
cancel me, even if they failed ;)
Ahah, good point! Slightly reworded.
Also "clear ... to".
isn't what I used above? "clear … to"
Well, yes, but still this sentence doesn't make sense.
Changed to "Can't clear plymouth filesystem cancel message: %m"
Didier
>From 08ea7ca56eaac8b5f0e6bcb949ea685a6166e08e Mon Sep 17 00:00:00 2001
From: Didier Roche
Date: Thu, 5 Feb 2015 17:08:18 +0100
Subject: [PATCH 3/9] Connect to plymouth and support cancellation of in
progress fsck
Try to connect and send to plymouth (if running) some checked report progress,
using direct plymouth protocole.
Update message is the following:
fsckd:::
* num_devices corresponds to the current number of devices being checked (int)
* progress corresponds to the current minimum percentage of all devices being
checked (float, from 0 to 100)
* string is a translated message ready to be displayed by the plymouth theme
displaying the information above. It can be overriden by plymouth themes
supporting i18n.
Grab in fsckd plymouth watch key Control+C, and propagate this cancel request
to systemd-fsck which will terminate fsck.
Send a message to signal to user what key we are grabbing for fsck cancel.
Message is: fsckd-cancel-msg:
Where string is a translated string ready to be displayed by the plymouth theme
indicating that Control+C can be used to cancel current checks. It can be
overriden (matching only fsckd-cancel-msg prefix) for themes supporting i18n.
---
src/fsck/fsck.c | 33
src/fsckd/fsckd.c | 146 +-
src/fsckd/fsckd.h | 4 ++
3 files changed, 173 insertions(+), 10 deletions(-)
diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index 9ecba99..e718534 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -132,7 +132,7 @@ static void test_files(void) {
}
-static int process_progress(int fd, dev_t device_num) {
+static int process_progress(int fd, pid_t fsck_pid, dev_t device_num) {
_cleanup_fclose_ FILE *f = NULL;
usec_t last = 0;
_cleanup_close_ int fsckd_fd = -1;
@@ -153,11 +153,13 @@ static int process_progress(int fd, dev_t device_num) {
while (!feof(f)) {
int pass;
+size_t buflen;
size_t cur, max;
-ssize_t n;
+ssize_t r;
usec_t t;
_cleanup_free_ char *device = NULL;
FsckProgress progress;
+FsckdMessage fsckd_message;
if (fscanf(f, "%i %lu %lu %ms", &pass, &cur, &max, &device) != 4)
break;
@@ -175,9 +177,19 @@ static int process_progress(int fd, dev_t device_num) {
progress.max = max;
progress.pass = pass;
-n = send(fsckd_fd, &progress, sizeof(FsckProgress), 0);
-if (n < 0 || (size_t) n < sizeof(FsckProgress))
+r = send(fsckd_fd, &progress, sizeof(FsckProgress), 0);
+if (r < 0 || (size_t) r < sizeof(FsckProgress))
log_warning_errno(errno, "Cannot communicate fsck progress to fsckd: %m");
+
+/* get fsckd requests, only read when we have coherent size data */
+r = ioctl(fsckd_fd, FIONREAD, &buflen);
+if (r == 0 && (size_t) buflen >= sizeof(FsckdMessage)) {
+r = recv(fsckd_fd, &fsckd_message, sizeof(FsckdMessage), 0);
+if (r > 0 && fsckd_message.cancel == 1) {
+log_info("Request to cancel fsck from fsckd");
+kill(fsck_pid, SIGTERM);
+}
+}
}
return 0;
@@ -187,6 +199,7 @@ int main(int argc, char *argv[]) {
const char *cmdline[9];
int i = 0, r = EXIT_FAILURE, q;
pid_t pid;
+int progress_rc;
siginfo_t status;
_cleanup_udev_unref_ struct udev *udev = NULL;
_cleanup_udev_device_unref_ struct udev_device *udev_device = NULL;
@@ -328,7 +341,7 @@ int main(int argc, char *argv[]) {
progress_pipe[1] = safe_close(progress_pipe[1]);
if (pr
Re: [systemd-devel] [PATCH 4/9] Add gettext support
>From 9227f9a919084f937fd29856935016e0ee9e754e Mon Sep 17 00:00:00 2001
From: Didier Roche
Date: Thu, 29 Jan 2015 16:12:58 +0100
Subject: [PATCH 4/9] Add gettext support
---
configure.ac | 1 +
src/shared/util.c | 8
src/shared/util.h | 2 ++
3 files changed, 11 insertions(+)
diff --git a/configure.ac b/configure.ac
index 277addb..9a2235b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -73,6 +73,7 @@ AS_IF([test -z "$INTLTOOL_POLICY_RULE"], [
GETTEXT_PACKAGE=systemd
AC_SUBST(GETTEXT_PACKAGE)
+AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE, "$GETTEXT_PACKAGE", [systemd])
AC_PROG_MKDIR_P
AC_PROG_LN_S
diff --git a/src/shared/util.c b/src/shared/util.c
index ba035ca..deb9839 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -25,6 +25,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -74,6 +76,7 @@
#include
#endif
+#include "config.h"
#include "macro.h"
#include "util.h"
#include "ioprio.h"
@@ -5782,6 +5785,11 @@ void *xbsearch_r(const void *key, const void *base, size_t nmemb, size_t size,
return NULL;
}
+void init_gettext(void) {
+setlocale(LC_ALL, "");
+textdomain(GETTEXT_PACKAGE);
+}
+
bool is_locale_utf8(void) {
const char *set;
static int cached_answer = -1;
diff --git a/src/shared/util.h b/src/shared/util.h
index a83b588..45cb094 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -737,6 +737,8 @@ void *xbsearch_r(const void *key, const void *base, size_t nmemb, size_t size,
int (*compar) (const void *, const void *, void *),
void *arg);
+#define _(String) gettext (String)
+void init_gettext(void);
bool is_locale_utf8(void);
typedef enum DrawSpecialChar {
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/9] systemd-fsck: always connect to systemd-fsckd
>From 6006bedd30530a91c2dee7e3822a8840799752e4 Mon Sep 17 00:00:00 2001
From: Didier Roche
Date: Mon, 26 Jan 2015 16:01:11 +0100
Subject: [PATCH 2/9] systemd-fsck: always connect to systemd-fsckd
Remove the plymouth running or show-status checks from systemd-fsck. Instead,
always connect to systemd-fsckd socket, and let this one decide if we display
progress or not.
---
src/fsck/fsck.c | 12
src/fsckd/fsckd.c | 8 +---
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index 6ccb2e7..9ecba99 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -45,7 +45,6 @@
static bool arg_skip = false;
static bool arg_force = false;
-static bool arg_show_progress = false;
static const char *arg_repair = "-a";
static void start_target(const char *target) {
@@ -131,8 +130,6 @@ static void test_files(void) {
}
#endif
-if (access("/run/systemd/show-status", F_OK) >= 0 || plymouth_running())
-arg_show_progress = true;
}
static int process_progress(int fd, dev_t device_num) {
@@ -286,11 +283,10 @@ int main(int argc, char *argv[]) {
log_warning_errno(r, "fsck.%s cannot be used for %s: %m", type, device);
}
-if (arg_show_progress)
-if (pipe(progress_pipe) < 0) {
-log_error_errno(errno, "pipe(): %m");
-return EXIT_FAILURE;
-}
+if (pipe(progress_pipe) < 0) {
+log_error_errno(errno, "pipe(): %m");
+return EXIT_FAILURE;
+}
cmdline[i++] = "/sbin/fsck";
cmdline[i++] = arg_repair;
diff --git a/src/fsckd/fsckd.c b/src/fsckd/fsckd.c
index 39fe899..6b2eeb0 100644
--- a/src/fsckd/fsckd.c
+++ b/src/fsckd/fsckd.c
@@ -259,9 +259,11 @@ static int manager_new(Manager **ret, int fd) {
return r;
m->connection_fd = fd;
-m->console = fopen("/dev/console", "we");
-if (!m->console)
-return log_warning_errno(errno, "Can't connect to /dev/console: %m");
+if (access("/run/systemd/show-status", F_OK) >= 0) {
+m->console = fopen("/dev/console", "we");
+if (!m->console)
+return log_warning_errno(errno, "Can't connect to /dev/console: %m");
+}
m->percent = 100;
*ret = m;
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/9] fsckd daemon for inter-fsckd communication
Hey,
Martin, while distro-patching ubuntu based on 219 told me that the
patches didn't apply cleanly anymore (some po, man pages and strappenda
-> strjoina changes). I did rebase on latest master then and repost here
the whole set of patches.
Also, we did notice that plymouth (at boot) and plymouth-x11 didn't
react the same way on Control+C, so I changed slightly the keys sent and
how we detect it to match what plymouth at boot expect.
With those, I hope that everything should be good to go.
Cheers,
Didier
>From 9f053f80b916642fd1049bb45fafda456a7484c3 Mon Sep 17 00:00:00 2001
From: Didier Roche
Date: Wed, 4 Feb 2015 16:42:47 +0100
Subject: [PATCH 1/9] fsckd daemon for inter-fsckd communication
Add systemd-fsckd multiplexer which accepts multiple systemd-fsck
instances to connect to it and sends progress report. systemd-fsckd then
computes and writes to /dev/console the number of devices currently being
checked and the minimum fsck progress. This will be used for interactive
progress report and cancelling in plymouth.
systemd-fsckd stops on idle when no systemd-fsck is connected.
Make the necessary changes to systemd-fsck to connect to the systemd-fsckd
socket.
---
.gitignore | 1 +
Makefile.am| 13 ++
src/fsck/fsck.c| 88
src/fsckd/Makefile | 1 +
src/fsckd/fsckd.c | 404 +
src/fsckd/fsckd.h | 34 +
6 files changed, 484 insertions(+), 57 deletions(-)
create mode 12 src/fsckd/Makefile
create mode 100644 src/fsckd/fsckd.c
create mode 100644 src/fsckd/fsckd.h
diff --git a/.gitignore b/.gitignore
index 75699ca..970b9cb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -77,6 +77,7 @@
/systemd-evcat
/systemd-firstboot
/systemd-fsck
+/systemd-fsckd
/systemd-fstab-generator
/systemd-getty-generator
/systemd-gnome-ask-password-agent
diff --git a/Makefile.am b/Makefile.am
index 51c6d33..f8c425b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -391,6 +391,7 @@ rootlibexec_PROGRAMS = \
systemd-remount-fs \
systemd-reply-password \
systemd-fsck \
+ systemd-fsckd \
systemd-machine-id-commit \
systemd-ac-power \
systemd-sysctl \
@@ -2357,6 +2358,18 @@ systemd_fsck_LDADD = \
libsystemd-shared.la
# --
+systemd_fsckd_SOURCES = \
+ src/fsckd/fsckd.c \
+ $(NULL)
+
+systemd_fsckd_LDADD = \
+ libsystemd-internal.la \
+ libsystemd-label.la \
+ libsystemd-shared.la \
+ libudev-internal.la \
+ $(NULL)
+
+# --
systemd_machine_id_commit_SOURCES = \
src/machine-id-commit/machine-id-commit.c \
src/core/machine-id-setup.c \
diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index 78ceeb6..6ccb2e7 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "sd-bus.h"
#include "libudev.h"
@@ -39,6 +40,8 @@
#include "fileio.h"
#include "udev-util.h"
#include "path-util.h"
+#include "socket-util.h"
+#include "fsckd/fsckd.h"
static bool arg_skip = false;
static bool arg_force = false;
@@ -132,58 +135,36 @@ static void test_files(void) {
arg_show_progress = true;
}
-static double percent(int pass, unsigned long cur, unsigned long max) {
-/* Values stolen from e2fsck */
-
-static const int pass_table[] = {
-0, 70, 90, 92, 95, 100
+static int process_progress(int fd, dev_t device_num) {
+_cleanup_fclose_ FILE *f = NULL;
+usec_t last = 0;
+_cleanup_close_ int fsckd_fd = -1;
+static const union sockaddr_union sa = {
+.un.sun_family = AF_UNIX,
+.un.sun_path = FSCKD_SOCKET_PATH,
};
-if (pass <= 0)
-return 0.0;
-
-if ((unsigned) pass >= ELEMENTSOF(pass_table) || max == 0)
-return 100.0;
-
-return (double) pass_table[pass-1] +
-((double) pass_table[pass] - (double) pass_table[pass-1]) *
-(double) cur / (double) max;
-}
-
-static int process_progress(int fd) {
-_cleanup_fclose_ FILE *console = NULL, *f = NULL;
-usec_t last = 0;
-bool locked = false;
-int clear = 0;
+fsckd_fd = socket(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0);
+if (fsckd_fd < 0)
+return log_warning_errno(errno, "Cannot open fsckd socket, we won't report fsck progress: %m");
+if (connect(fsckd_fd, &sa.sa, offsetof(struct sockaddr_un, sun_path) + strlen(sa.un.sun_path)) < 0)
+return log_warning_errno(errno, "Cannot connect to fsckd socket, we won't report fsck progress: %m");
f = fdopen(fd, "r");
-if (!f) {
-safe_close(fd);
-return -errno;
-}
-
-console = fopen("/dev/console", "we");
-if (!console)
-return -ENOMEM;
+if (!f)
+
Re: [systemd-devel] [ANNOUNCE] systemd 219
2015-02-18 12:19 GMT+02:00 Lennart Poettering : > On Wed, 18.02.15 12:13, Joonas Sarajärvi (m...@iki.fi) wrote: > >> 2015-02-18 12:07 GMT+02:00 Lennart Poettering : >> > On Wed, 18.02.15 06:22, Andrei Borzenkov (arvidj...@gmail.com) wrote: >> >> >> >> >> btrfs checksumming theoretically allows you to transparently recover >> >> after media corruption if filesystem has redundancy (more than one copy >> >> of data). Journald checksum will probably detect corruption, but can it >> >> repair it? >> > >> > No it cannot. >> > >> > But btrfs checksumming cannot fix things for you either if you lose >> > non-trivial amounts of data. It might be able to fix a few bits of >> > errors, but not non-trivial amounts. I mean, that's a simple property >> > of error correction codes: the more you want to be able to correct the >> > longer must your checksum be. Neither btrfs' nor journald's are >> > substantial enough to correct even a sector... >> > >> > Lennart >> > >> >> My impression is that btrfs can fix the corruption in cases where a >> e.g. a RAID1 of btrfs is used. > > FS_NOCOW does no effect btrfs raid settings. If you want this kind of > data redundancy then it will continue to be available even though we > set FS_NOCOW now. > Thank you for the quick response. Do you mean that btrfs scrub will be able to detect which of the copies is correct, if one of the copies of a file flagged with FS_NOCOW gets changed due to disk corruption? My impression is that FS_NOCOW would result in the redundant copies of file data not having checksums that'd be correctly maintained. So btrfs scrub could possibly detect that the copies differ, but it would not be able to decide which one to discard. AFAIK btrfs would normally able to do this, write a new copy of the intact file data and discard the corrupt one. -Joonas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 219
On Wed, 18.02.15 12:13, Joonas Sarajärvi (m...@iki.fi) wrote: > 2015-02-18 12:07 GMT+02:00 Lennart Poettering : > > On Wed, 18.02.15 06:22, Andrei Borzenkov (arvidj...@gmail.com) wrote: > > >> > >> btrfs checksumming theoretically allows you to transparently recover > >> after media corruption if filesystem has redundancy (more than one copy > >> of data). Journald checksum will probably detect corruption, but can it > >> repair it? > > > > No it cannot. > > > > But btrfs checksumming cannot fix things for you either if you lose > > non-trivial amounts of data. It might be able to fix a few bits of > > errors, but not non-trivial amounts. I mean, that's a simple property > > of error correction codes: the more you want to be able to correct the > > longer must your checksum be. Neither btrfs' nor journald's are > > substantial enough to correct even a sector... > > > > Lennart > > > > My impression is that btrfs can fix the corruption in cases where a > e.g. a RAID1 of btrfs is used. FS_NOCOW does no effect btrfs raid settings. If you want this kind of data redundancy then it will continue to be available even though we set FS_NOCOW now. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 219
2015-02-18 12:07 GMT+02:00 Lennart Poettering : > On Wed, 18.02.15 06:22, Andrei Borzenkov (arvidj...@gmail.com) wrote: >> >> btrfs checksumming theoretically allows you to transparently recover >> after media corruption if filesystem has redundancy (more than one copy >> of data). Journald checksum will probably detect corruption, but can it >> repair it? > > No it cannot. > > But btrfs checksumming cannot fix things for you either if you lose > non-trivial amounts of data. It might be able to fix a few bits of > errors, but not non-trivial amounts. I mean, that's a simple property > of error correction codes: the more you want to be able to correct the > longer must your checksum be. Neither btrfs' nor journald's are > substantial enough to correct even a sector... > > Lennart > My impression is that btrfs can fix the corruption in cases where a e.g. a RAID1 of btrfs is used. As journal performance has already been sufficient for my needs on btrfs, I would prefer to be able to configure journald so that it'd keep the journal files with default flags. -Joonas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tmpfiles.d specifier support on "argument" when operating on files
On Tue, 17.02.15 17:35, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
Please fix this for all arguments, not just symlinks.
> diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
> index c948d4d..1b35b8e 100644
> --- a/src/tmpfiles/tmpfiles.c
> +++ b/src/tmpfiles/tmpfiles.c
> @@ -1590,6 +1590,12 @@ static int parse_line(const char *fname, unsigned
> line, const char *buffer) {
> i.argument = strappend("/usr/share/factory/",
> i.path);
> if (!i.argument)
> return log_oom();
> +} else {
> +r = specifier_printf(i.argument,
> specifier_table, NULL, &i.argument);
Here's a memory leak, you need to free the old i.argument.
Indentation! Please have a look at CODING_STYLE. You need to indent by
8ch. 4ch indenting is not acceptable.
> +if (r < 0) {
> +log_error("[%s:%u] Failed to replace specifiers:
> %s", fname, line, path);
> +return r;
> +}
A good candidate for log_error_errno().
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] [ANNOUNCE] systemd 219
On Wed, 18.02.15 06:22, Andrei Borzenkov (arvidj...@gmail.com) wrote: > В Wed, 18 Feb 2015 01:14:44 +0100 > Zbigniew Jędrzejewski-Szmek пишет: > > > On Tue, Feb 17, 2015 at 08:05:29PM +0100, Goffredo Baroncelli wrote: > > > Hi Lennart, > > > > > > On 2015-02-16 23:59, Lennart Poettering wrote: > > > > * journald now sets the special FS_NOCOW file flag for its > > > > journal files. This should improve performance on btrfs, by > > > > avoiding heavy fragmentation when journald's write-pattern > > > > is used on COW file systems. It degrades btrfs' data > > > > integrity guarantees for the files to the same levels as for > > > > ext3/ext4 however. This should be OK though as journald does > > > > its own data integrity checks and all its objects are > > > > checksummed on disk. Also, journald should handle btrfs disk > > > > full events a lot more gracefully now, by processing SIGBUS > > > > errors, and not relying on fallocate() anymore. > > > > > > If I read correctly the code, the FS_NOCOW is a temporary workaround, i.e. > > > when the file is closed (or rotated ?) the FS_NOCOW flags is unset again. > > > It is true ? > > Yes, but you miss the point in general. FS_NOCOW is set during the > > entire time when the file is being written to, which could be months, > > and then it is unset when the file will not be written to anymore. So > > indeed, the file is not protected by btrfs checksums for the majority > > of time, but journald does its own checksumming, so the contents are > > protected in a different way. > > > > btrfs checksumming theoretically allows you to transparently recover > after media corruption if filesystem has redundancy (more than one copy > of data). Journald checksum will probably detect corruption, but can it > repair it? No it cannot. But btrfs checksumming cannot fix things for you either if you lose non-trivial amounts of data. It might be able to fix a few bits of errors, but not non-trivial amounts. I mean, that's a simple property of error correction codes: the more you want to be able to correct the longer must your checksum be. Neither btrfs' nor journald's are substantial enough to correct even a sector... 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] [ANNOUNCE] systemd 219
On Tue, 17.02.15 20:05, Goffredo Baroncelli (kreij...@libero.it) wrote: > Hi Lennart, > > On 2015-02-16 23:59, Lennart Poettering wrote: > > * journald now sets the special FS_NOCOW file flag for its > > journal files. This should improve performance on btrfs, by > > avoiding heavy fragmentation when journald's write-pattern > > is used on COW file systems. It degrades btrfs' data > > integrity guarantees for the files to the same levels as for > > ext3/ext4 however. This should be OK though as journald does > > its own data integrity checks and all its objects are > > checksummed on disk. Also, journald should handle btrfs disk > > full events a lot more gracefully now, by processing SIGBUS > > errors, and not relying on fallocate() anymore. > > If I read correctly the code, the FS_NOCOW is a temporary workaround, i.e. > when the file is closed (or rotated ?) the FS_NOCOW flags is unset again. > It is true ? Well, we try to unset it, but this is not allowed by btrfs. However, given that it might be allowed one day, we do it anyway. In effect this means FS_NOCOW is set for good once we turn it on. 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] [ANNOUNCE] systemd 219
On Tue, 17.02.15 23:30, Colin Guthrie (gm...@colin.guthr.ie) wrote: > Lennart Poettering wrote on 17/02/15 10:08: > >> > mount something-else /foo > >> > systemctl start foo.mount > > In this case the second line is a NOP, since the first line already > > mounted something on /foo, and thus made foo.mount active. > > So, even if foo.mount (the actual unit file) specifies it's > What=something (not What=something-else) the fact that *anything* is > mounted to /foo is sufficient to make the foo.mount unit active? Yes, and this always has been that way. > This seems somewhat counter-intuitive to me. I can understand why from > an implementation perspective - the mount units are all geared around > the mountpoint not the What=, but it's certainly not what I'd expect as > a user. Well it's the only logic that can work really, already since the same device node is usually known to the kernel by a different name thatn to userspace. Trying to always map that is really nasty, as one can see with the GPT generator complexity. > Wouldn't it be better if there was some other state - e.g. "conflict" if > something other than the desired device was mounted to the specified > destination? I think it's really safe not to consider that a problem. 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] feature request: dlopen
On Tue, 17.02.15 20:24, Luke Kenneth Casson Leighton (l...@lkcl.net) wrote: > i note that there was announcement recently that the systemd team > 'listens to users', so i am taking you at your word on that. Hmm, I am not aware of such an "announcement". I generally listen though, but I don't always agree. I particularly don't listen to badly researched conspiracy theories. > so i'm not going to "protest" - i'm going to try a different approach. > i'd like you to look at this list of debian packages that are > dependent on libsystemd0: > http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt Well, I doubt this is correct, and even if it was, I am not sure what systemd upstream has to do with it. Convince the upstream developers in question not to link against systemd's libraries, or convince the distros not to package it like that. We just offer a library, which apparently is interesting to people to use, but whether they use it is really not up to us. Also, what precisely is the problem with having a dependency on that library? If it's pulled in and nothing else of systemd, where precisely is your problem? It's just code lying around, and there is tons of stuff like that. If you think that code we wrote is really evil shit, that should never touch your system, then I figure it's too late. The folks involved in systemd touched a lot more of your system, outside of the systemd umbrella, our code is in much of the stack, in the desktop and in the kernel. If you want to avoid using the code we wrote you'll have a really hard time. > as i am partly writing to a public audience who may not be so > knowledgeable, please excuse me for describing that the advantages, > are, as you know, that a pre-compiled package may, at runtime, detect > what is available to it and use it. it may even be configured via a > config option to disable the use of that functionality at runtime even > if the dynamic library is present. you know this. dlopen() is something the programs *using* a library must make use of, it's not up to us, the providers of the library. > i am one of the few people who can cut through all that, who has gone > to the trouble of digging into why libsystemd0 is found to be so > objectionable. Good for you! > i have to tell you: i even heard, on slashdot, that microsoft is now > using - to significant success - the situation surrounding systemd as > a sales pitch to have GNU/linux systems successfully replaced with > windows servers. Good one! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Looping too fast. Throttling execution a little
Hi there
---
I am running a fedora21 box that acts as a libvirt host for lxc containers
guests
This is based on vanilla fedora (maybe a little bit behind by a few weeks) and
a locally rebuild libvirt based on 1.2.11
root@bigjohn /var/log # uname -a
Linux bigjohn.pl.sophia.inria.fr 3.18.3-201.fc21.x86_64 #1 SMP Mon Jan 19
15:59:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
root@bigjohn /var/log # rpm -q libvirt
libvirt-1.2.11-1.x86_64
guests typically are based on fedora20, fedora14, and debian jessie
—
The symptom I have is, after some time (typically a week) guests become real
slow to answer; trying to ssh into a guest takes in the 5 to 10 seconds.
The most visible of these guests runs feodra20; when this problem occurs I can
generally get the guest to answer again with its expected pace by just
restarting the guest
I have been seeing this for quite some time - something like 6-9 months,
starting with the host running fedora20/libvirt-1.2.5
I was hoping this would go away with fedora21, but that is not the case
—
Digging a little more today, I found the following on the host side
As there was a message on this list in december named
[systemd-devel] Cannot use systemctl after heavy swapping
I figured I would report what I can see on my host
root@bigjohn /vservers # journalctl -b -f
-- Logs begin at Fri 2014-09-05 04:28:57 CEST. --
Feb 18 10:38:25 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
Throttling execution a little.
Feb 18 10:38:26 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
Throttling execution a little.
Feb 18 10:38:28 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
Throttling execution a little.
Feb 18 10:38:30 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
Throttling execution a little.
Feb 18 10:38:31 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
Throttling execution a little.
Feb 18 10:38:33 bigjohn.pl.sophia.inria.fr systemd[1]: Looping too fast.
Throttling execution a little.
root@bigjohn /vservers # systemctl list-unit-files
^C
# strace -p 1
<…>
recvmsg(42, 0x7fff3ea64d00, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1
EAGAIN (Resource temporarily unavailable)
timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={0, 1}},
NULL) = 0
epoll_wait(4, {{EPOLLIN, {u32=3, u64=3}}}, 36, 0) = 1
clock_gettime(CLOCK_BOOTTIME, {1959524, 957887776}) = 0
read(3, "\1\0\0\0\0\0\0\0", 8) = 8
recvmsg(42, 0x7fff3ea64d00, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1
EAGAIN (Resource temporarily unavailable)
timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={0, 1}},
NULL) = 0
epoll_wait(4, {{EPOLLIN, {u32=3, u64=3}}}, 36, 0) = 1
clock_gettime(CLOCK_BOOTTIME, {1959524, 958282696}) = 0
read(3, "\1\0\0\0\0\0\0\0", 8) = 8
recvmsg(42, 0x7fff3ea64d00, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1
EAGAIN (Resource temporarily unavailable)
timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={0, 1}},
NULL) = 0
epoll_wait(4, {{EPOLLIN, {u32=3, u64=3}}}, 36, 0) = 1
clock_gettime(CLOCK_BOOTTIME, {1959524, 958617432}) = 0
^CProcess 1 detached
——
I’d very much like to help in providing more data when this problem occurs
again (although I will reboot the host right now I am afraid)
Just let me know what commands I should do if I see this again
Thanks — Thierry
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] Added support for Uplink Failure Detection using BindCarrier
Hi Andrei,
> This means if link was administratively down it will be reactivated again
>
> ip link set dev down-link down
> unplug up-link
> plug up-link
>
> down-link is now up. Is it intentional?
At the time you issue "plug up-link" you don't know if the down-link is down
due to " ip link set dev down-link down" or " unplug up-link ".
Since the carrier of the down-link is bound to the up-link, any change in
up-link state (up & down) is propagated to the down-link, but to answer your
question I have no strong opinion for or against this behaviour.
Best Regards,
Alin
-Original Message-
From: Andrei Borzenkov [mailto:arvidj...@gmail.com]
Sent: Wednesday, February 18, 2015 3:43 AM
To: Rauta, Alin
Cc: t...@jklm.no; lenn...@poettering.net; zbys...@in.waw.pl; Kinsella, Ray;
systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] [PATCH v4] Added support for Uplink Failure
Detection using BindCarrier
В Tue, 17 Feb 2015 04:06:57 -0800
Alin Rauta пишет:
> +
> +static int link_handle_bound_to_list(Link *link) {
> +Link *l;
> +Iterator i;
> +int r;
> +bool required_up = false;
> +bool link_is_up = false;
> +
> +assert(link);
> +
> +if (hashmap_isempty(link->bound_to_links))
> +return 0;
> +
> +if (link->flags & IFF_UP)
> +link_is_up = true;
> +
> +HASHMAP_FOREACH (l, link->bound_to_links, i)
> +if (link_has_carrier(l)) {
> +required_up = true;
> +break;
> +}
> +
> +if (!required_up && link_is_up) {
> +r = link_down(link);
> +if (r < 0)
> +return r;
> +} else if (required_up && !link_is_up) {
> +r = link_up(link);
> +if (r < 0)
> +return r;
> +}
> +
> +return 0;
> +}
> +
This means if link was administratively down it will be reactivated again
ip link set dev down-link down
unplug up-link
plug up-link
down-link is now up. Is it intentional?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
Hi Luke, I am mostly a lurker on the systemd mailing list, so my opinion does not carry weight in this community. On Tue, Feb 17, 2015 at 9:24 PM, Luke Kenneth Casson Leighton wrote:> so i'm not going to "protest" - i'm going to try a different approach. > i'd like you to look at this list of debian packages that are > dependent on libsystemd0: > http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt I understood most of these dependencies to be indirect: Packages that depend on other packages that in turn depend on libsystemd. Is that correct? How many and which packages depend *directly* on libsystemd? Are the numbers by other people replying to this list correct, namely that the direct dependencies are < 100 packages? > i think the most important question to ask you at this point is: as a > team, were you aware of the extent to which libsystemd0 has become a > hard compile-time dependency on so many critical software packages in > use today? My understanding is that libsystemd is a dependency of some packages down low in the stack that is then (re-)used by other packages. And for those few packages it makes sense to depend on libsystemd: Those tend to provide services that do benefit from systemd features like socket activation. So not having this dependency does seriously hurt the systemd users. On the other hand the library is tiny and basically falls back to being a no-op in the case where systemd is not PID1, so it does not hurt non-systemd systems to have this library in any way. > we see that a debian developer has created unofficial packages > that, if installed, provide replacements for key strategic packages > entirely recompiled *without* systemd and without libsystemd0 being > present. Good for them. I see very little value in replacing a ~150KiB library that does nothing for the users these packages are targeting, but everybody is free to spend their time however they want. > moving on: in what adam wrote (rather hot-headedly, initially), he > goes on to mention that it would be perfectly reasonable to replicate > the effects of how he removed libsystemd0, in a way that would be far > less disruptive to end-users and sysadmins, and far less divisive: > dynamic library loading. Libsystemd's job is basically to provide exactly what you ask for: A wrapper around systemd functionality, that fails gracefully in case systemd is not used. That wrapper is nicely packaged up into a library so that upstream projects do not need to keep reimplementing the same dlopen, error handling, etc. over and over again. Your proposal is to ask every upstream project to add that same snippet of code? How about putting that into a library for easier reuse: Maybe libsystemdwrapper. That can then be wrapped in another wrapper when somebody freaks out about "everything is linking to libsystemdwrapper". Maybe just renaming libsystemd would suffice? I am sure hardly nobody would object to having a tiny "libyzy" on their system:-) > so can i leave it with you to consider whether the current situation > is tolerable or not? Again: I can in no way speak for the systemd project. But from where I stand the systemd project went out of their way to provide you with exactly what you are asking for in a way that is easy to reuse by upstream projects. That is libsystemd. Apparently you find that solution objectionable, but I do not understand why. I would personally like to see a "libinitd" which brings the socket activation features that is provided to daemons as part of libsystemd to other init systems (that can support those). That would make it so much easier for upstreams to support more than one init system. But I would expect that to be implemented by the teams working on alternatives to systemd or by distributions centered around other init systems. > i am one of the few people who can cut through all that, who has gone > to the trouble of digging into why libsystemd0 is found to be so > objectionable. my take on the matter is that the technical arguments > - benefits or otherwise - of systemd and its alternatives - is > completely irrelevant. over time people *will* develop alternatives > (and are already doing so: mdev, eudev, uselessd, openrc and many > more). Sure. I am looking forward to that! I am convinced a bit of competition and fresh ideas will do systemd a hell of a lot of good:-) > no, i feel that it really does have nothing to do with the technical > benefits of the available options: what people are finding completely > objectionable is that they have *no good choices*. it's "use systemd > or go away" - and unfortunately almost without exception (slackware > and FreeBSD being two notable ones) that "piss off" attitude is being > replicated across *the entire GNU/Linux Distro world*. the situation > is completely unprecedented and without parallel in the short history > of software libre (and that's something that, honestly, i find to be > real
