Re: [systemd-devel] Proposal: integrate biosdevname into systemd tree
Am 04.01.2013 10:02, schrieb Alexander E. Patrakov: > [Yes I know that this mail is several months too late, but better late > then never. Also it is too verbose.] > > As of systemd-189, the persistent rule generators for network cards > were removed. They did serve a purpose - they prevented the multiple > network cards from being randomly renumbered during every boot due to > bus scanning and module loading being performed in parallel > threads/processes (i.e. modules were loaded in unpredictable order) but hopefully /etc/udev/rules.d/70-persistent-net.rules will be recognized forever if it exists because there are many servers especially virtual ones where you hardly need to control ethernet device names to avoid breaking iptables-scripts as example keep in mind there are MANY setups which do not need nor want biosdevname and are bootet with biosdevname=0 on the kernel line P.S.: i HATE it to need "ifconfig -a" and hack "70-persistent-net.rules" by hand instead as all the years open it and change back the last line to "eth0" after probe-restore of a virtual machine to temporary access a datarecovery backup from some weeks ago 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] Offtopic question.
Hi, I've read about the possible bugs. About the combination between mmap and mandatory locks: of course the mapping of memory is causing troubles when a mandatory lock is set. The mapped region should or forward the lock to the new memory location (where remapped) or the mmap should be denied, unless the locking allows it (when the mandatory lock is read, allow read access, if a write lock, deny all others, also mmap). The first is causing too much overhead, so the second is in my opinion the best option. Second, when a write is allowed, and a read lock is set (which is possible according to http://kernel.org/doc/Documentation/filesystems/mandatory-locking.txt then the implementation is not right. Like other operations which require exclusive access to a region of a file, like writes do, denying other writes to the same region at the same moment, I guess this locking should also behave like that. If this isn't the case (where theoretically it is possible that writes are done when a read lock is set) then there is something wrong. Stef ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: integrate biosdevname into systemd tree
2013/1/4 Reindl Harald : > but hopefully /etc/udev/rules.d/70-persistent-net.rules will be recognized > forever if it exists because there are many servers especially virtual > ones where you hardly need to control ethernet device names to avoid > breaking iptables-scripts as example Yes, the existing rules will continue to be recognized. The bug is that even they are intrinsically unreliable (as happened with that rented server), so I think you actually don't want that. > keep in mind there are MANY setups which do not need nor want > biosdevname and are bootet with biosdevname=0 on the kernel line And that's indeed something that we need to think about. The real problem is that it is hard to explain the whole interface-renumbering issue and the reasons why he needs persistence to an average sysadmin. It's too low level. IMHO it is safer to always install biosdevname and use it even if not strictly required than to rely on the sysadmin to know about the issue. For me, even with the old solution in place, the bug surfaced after ~10 reboots. That's more than an average sysadmin is willing to test before saying "I think it always boots as it should". Besides, the sysadmin can be wrong about not needing the persistent names. Again, my position is: better safe than sorry, especially with remotely-managed servers. > P.S.: i HATE it to need "ifconfig -a" and hack "70-persistent-net.rules" > by hand instead as all the years open it and change back the last line > to "eth0" after probe-restore of a virtual machine to temporary access > a datarecovery backup from some weeks ago With biosdevname, the interface names are determined only by PCI bus slot. I.e., if the replacement card is inserted into the same slot as the failed one, the name won't change. And in virtual machines biosdevname deactivates itself automatically. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: integrate biosdevname into systemd tree
Am 04.01.2013 10:40, schrieb Alexander E. Patrakov:
> 2013/1/4 Reindl Harald :
>> but hopefully /etc/udev/rules.d/70-persistent-net.rules will be recognized
>> forever if it exists because there are many servers especially virtual
>> ones where you hardly need to control ethernet device names to avoid
>> breaking iptables-scripts as example
>
> Yes, the existing rules will continue to be recognized. The bug is
> that even they are intrinsically unreliable (as happened with that
> rented server), so I think you actually don't want that.
how can something like this be unreliable?
hwaddresses does not change randomly
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:50:56:bd:00:04", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
>> keep in mind there are MANY setups which do not need nor want
>> biosdevname and are bootet with biosdevname=0 on the kernel line
>
> And that's indeed something that we need to think about. The real
> problem is that it is hard to explain the whole interface-renumbering
> issue and the reasons why he needs persistence to an average sysadmin.
> It's too low level. IMHO it is safer to always install biosdevname and
> use it even if not strictly required than to rely on the sysadmin to
> know about the issue.
currently syaadmins who knew over years how to handle
70-persistent-net.rules are more pissed of than ever before
>> P.S.: i HATE it to need "ifconfig -a" and hack "70-persistent-net.rules"
>> by hand instead as all the years open it and change back the last line
>> to "eth0" after probe-restore of a virtual machine to temporary access
>> a datarecovery backup from some weeks ago
>
> With biosdevname, the interface names are determined only by PCI bus
> slot. I.e., if the replacement card is inserted into the same slot as
> the failed one
you are missing the real problem with the new shiny biosdevname
nobody can rely on eth0 any longer
if have thousands of firewall-scripts and configurations which
are assuming eth0=LAN, eth1=WAn as example, the benefit of such
scripts is that they can be easily adopted to a new but compareable
setup and basic rules are always the same
with the new shiny names this you have to replace interface names
if you are knowing your scripts and iptables rules you do not
always look "who is WAN interface here", you like to see "eth1"
and know what it does
> the name won't change. And in virtual machines
> biosdevname deactivates itself automatically
fine, even there i stay with force disable it because
after the large changes in a few years i do not trust
any behavior to stay since subsystems are changed and
rewritten like a slut changes her man :-)
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] Proposal: integrate biosdevname into systemd tree
2013/1/4 Reindl Harald :
> how can something like this be unreliable?
> hwaddresses does not change randomly
>
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:50:56:bd:00:04", ATTR{dev_id}=="0x0",
> ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
Good question, and it hits the very core of the problem. I don't know
the answer, maybe we should wait for Kay or Lennart to explain that. I
only know that it IS unreliable if the following renames have to be
the end result:
[removed card] -> eth0 (non-existing)
eth0 -> eth1
eth1 -> eth2
and it is claimed to be reliable for the case when the destination
names are not eth*, e.g.:
eth0 -> lan
eth1 -> wan
> currently syaadmins who knew over years how to handle
> 70-persistent-net.rules are more pissed of than ever before
Yeah, resistance to ANY change is an integral part of a human nature.
And it also makes a good sysadmin. The problem, as stated multiple
times, is that same-namespace renames do not work reliably, cannot
work reliably, and that the official preferred solution (yet to be
drilled into sysadmins' brains) now is to avoid them completely.
> you are missing the real problem with the new shiny biosdevname
> nobody can rely on eth0 any longer
Yes, that's a problem.
> if have thousands of firewall-scripts and configurations which
> are assuming eth0=LAN, eth1=WAn as example, the benefit of such
> scripts is that they can be easily adopted to a new but compareable
> setup and basic rules are always the same
You can achieve the same by manually writing the equivalent of the
persistent rules by hand, just don't name the renamed interfaces eth*.
Existing rules override what biosdevname thinks. And you can use
variables like $LAN and $WAN in the scripts.
--
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: integrate biosdevname into systemd tree
On Fri, Jan 4, 2013 at 10:02 AM, Alexander E. Patrakov wrote: > What worries me now is that I was able to learn about the recommended > replacement (biosdevname) only via IRC, from Kay Sievers. There are no > pointers to biosdevname in any documentation that comes with > systemd-196. How are distributions supposed to learn that they have to > install it by default? And some of them don't learn. Here are some > examples from rolling-release or beta distributions: We plan to have something in a future systemd version, which should be able to cover all the common use cases. It will be similar to the /dev/disk/by-*/ symlinks, just with the obvious limitations of a single name that is 15 characters long. The current systemd git code: http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c has some explanations in it. It already adds (currently unused) candidates for names in the udev database: # for i in /sys/class/net/*; do echo $(realpath $i); udevadm test-builtin net_id $i 2>/dev/null; echo; done /sys/devices/pci:00/:00:19.0/net/enp0s25 ID_NET_NAME_MAC=enxf0def180d479 ID_OUI_FROM_DATABASE=Wistron InfoComm (Kunshan)Co ID_NET_NAME_PATH=enp0s25 /sys/devices/pci:00/:00:1c.3/:05:00.0/net/ens1 ID_NET_NAME_MAC=enx0466 ID_NET_NAME_PATH=enp5s0 ID_NET_NAME_SLOT=ens1 /sys/devices/pci:00/:00:1c.1/:03:00.0/net/wlp3s0 ID_NET_NAME_MAC=wlx0024d7e31130 ID_OUI_FROM_DATABASE=Intel Corporate ID_NET_NAME_PATH=wlp3s0 /sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.6/net/wwp0s29u1u4i6 ID_NET_NAME_MAC=wwx028037ec0200 ID_NET_NAME_PATH=wwp0s29u1u4i6 We originally planned to use the biosdevname naming scheme, but it turns out that it on one hand not flexible enough, and on the other hand it "invents" its own enumeration based on crawling the entire system for all network hardware, and coming up with new numbers. This wasn't what we envision for systemd, so we decided to stick with the model closer to what we already use for the disks and other subsystems. It will not use the same names as biosdevname, especially not invent new numbers when the PCI spec and the kernel already have numbers sufficiently stable enough. It's all still blurry, how the facility will look like in the end, and it we need to find out with which policy to apply the currently "dead" names to the actual interfaces. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: integrate biosdevname into systemd tree
Op 4 jan. 2013, om 10:54 heeft Reindl Harald het volgende geschreven: > > > Am 04.01.2013 10:40, schrieb Alexander E. Patrakov: >> 2013/1/4 Reindl Harald : >>> but hopefully /etc/udev/rules.d/70-persistent-net.rules will be recognized >>> forever if it exists because there are many servers especially virtual >>> ones where you hardly need to control ethernet device names to avoid >>> breaking iptables-scripts as example >> >> Yes, the existing rules will continue to be recognized. The bug is >> that even they are intrinsically unreliable (as happened with that >> rented server), so I think you actually don't want that. > > how can something like this be unreliable? > hwaddresses does not change randomly Actually, they do for a lot of 'embedded' setups. If you have an SMSC usb-ethernet chip with a blank eeprom (e.g. a beagleboard xM) the kernel will assign a random mac on 1) every reboot (3.x kernels) or 2) every ifup (2.6.x kernels). If you have a board where the bootloader is supposed to read an eeprom or hidden register and pass it to the kernel this will fail if you use a devicetree enabled kernel since the kernel driver writers from the silicon vendor don't care about the bootloader (e.g. beaglebone). There are patches available to assign a static mac based on e.g. die IDs, but those aren't in mainine linux yet. And that's just for the 2 platforms I care for at $dayjob and I don't think they are the only ones. It sucks, it's a bug and must be fixed, but right now you can't say 'hwaddresses does not change randomly' :( regards, Koen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: integrate biosdevname into systemd tree
On Fri, Jan 4, 2013 at 1:07 PM, Koen Kooi wrote: > Op 4 jan. 2013, om 10:54 heeft Reindl Harald het > volgende geschreven: >> Am 04.01.2013 10:40, schrieb Alexander E. Patrakov: >>> 2013/1/4 Reindl Harald : but hopefully /etc/udev/rules.d/70-persistent-net.rules will be recognized forever if it exists because there are many servers especially virtual ones where you hardly need to control ethernet device names to avoid breaking iptables-scripts as example >>> >>> Yes, the existing rules will continue to be recognized. The bug is >>> that even they are intrinsically unreliable (as happened with that >>> rented server), so I think you actually don't want that. >> >> how can something like this be unreliable? >> hwaddresses does not change randomly > > Actually, they do for a lot of 'embedded' setups. If you have an SMSC > usb-ethernet chip with a blank eeprom (e.g. a beagleboard xM) the kernel will > assign a random mac on 1) every reboot (3.x kernels) or 2) every ifup (2.6.x > kernels). If you have a board where the bootloader is supposed to read an > eeprom or hidden register and pass it to the kernel this will fail if you use > a devicetree enabled kernel since the kernel driver writers from the silicon > vendor don't care about the bootloader (e.g. beaglebone). > There are patches available to assign a static mac based on e.g. die IDs, but > those aren't in mainine linux yet. And that's just for the 2 platforms I care > for at $dayjob and I don't think they are the only ones. > It sucks, it's a bug and must be fixed, but right now you can't say > 'hwaddresses does not change randomly' :( We see this since years, not only on "cheap" hardware. Things like this happens everywhere. The kernel exports the "source" of the address now though, and we should be able to skip the usage of the MAC entirely if it was created randomly. The old udev rules did not check for that, but the code in systemd now should do that properly already. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] fstab-overmount
From: John Lane
---
src/core/mount.c | 13 +++-
src/fstab-generator/fstab-generator.c | 58 +++
2 files changed, 51 insertions(+), 20 deletions(-)
diff --git a/src/core/mount.c b/src/core/mount.c
index f263d9b..b0a06e9 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -507,6 +507,9 @@ static int mount_fix_timeouts(Mount *m) {
static int mount_verify(Mount *m) {
bool b;
char *e;
+ char *ext, *suf;
+ int name_len;
+ char cm[strlen(UNIT(m)->id)];
assert(m);
if (UNIT(m)->load_state != UNIT_LOADED)
@@ -518,7 +521,15 @@ static int mount_verify(Mount *m) {
if (!(e = unit_name_from_path(m->where, ".mount")))
return -ENOMEM;
-b = unit_has_name(UNIT(m), e);
+ /* clean mount file name with any overmount suffix removed */
+ ext = strrchr(UNIT(m)->id,'.');
+ suf = strrchr(UNIT(m)->id,'_');
+ name_len = (suf ? suf : ext ) - UNIT(m)->id;
+strncpy(cm,UNIT(m)->id, name_len);
+strcpy(cm + name_len, ext);
+ log_debug("clean mount file name (with any overmount suffix removed):
%s", cm);
+
+b = unit_has_name(UNIT(m), e) || !strcmp(e,cm);
free(e);
if (!b) {
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index a0173d8..1f693fe 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -214,6 +214,9 @@ static int add_mount(const char *what, const char *where,
const char *type, cons
int passno, bool wait, bool noauto, bool nofail, bool
automount, bool isbind, bool isnetwork,
const char *source) {
char *name = NULL, *unit = NULL, *lnk = NULL, *device = NULL,
*automount_name = NULL, *automount_unit = NULL;
+char uniq_suffix[10] = ".mount";
+int uniq_num = 0;
+char *prior_unit = NULL;
FILE *f = NULL;
int r;
const char *post, *pre;
@@ -244,27 +247,37 @@ static int add_mount(const char *what, const char *where,
const char *type, cons
pre = SPECIAL_LOCAL_FS_PRE_TARGET;
}
-name = unit_name_from_path(where, ".mount");
-if (!name) {
-r = log_oom();
-goto finish;
-}
+do {
-unit = strjoin(arg_dest, "/", name, NULL);
-if (!unit) {
-r = log_oom();
-goto finish;
-}
+name = unit_name_from_path(where, uniq_suffix);
+if (!name) {
+r = log_oom();
+goto finish;
+}
-f = fopen(unit, "wxe");
-if (!f) {
-r = -errno;
-if (errno == EEXIST)
-log_error("Failed to create mount unit file %s, as it
already exists. Duplicate entry in /etc/fstab?", unit);
-else
-log_error("Failed to create unit file %s: %m", unit);
-goto finish;
-}
+unit = strjoin(arg_dest, "/", name, NULL);
+if (!unit) {
+r = log_oom();
+goto finish;
+}
+
+f = fopen(unit, "wxe");
+if (!f) {
+r = -errno;
+if (errno == EEXIST)
+{
+free(prior_unit);
+prior_unit = strdup(name);
+snprintf(uniq_suffix, 10, "_%d.mount",
uniq_num++);
+log_warning("Failed to create mount unit file
%s because it already exists (overmount entry in /etc/fstab?). Will retry with
suffix %s", unit, uniq_suffix);
+}
+else
+{
+log_error("Failed to create unit file %s: %m",
unit);
+goto finish;
+}
+}
+} while (!f);
fprintf(f,
"# Automatically generated by systemd-fstab-generator\n\n"
@@ -288,6 +301,13 @@ static int add_mount(const char *what, const char *where,
const char *type, cons
"Before=%s\n",
post);
+if (prior_unit) {
+fprintf(f,
+"After=%s\n",
+prior_unit);
+free(prior_unit);
+}
+
fprintf(f,
"\n"
"[Mount]\n"
--
1.8.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/3] systemd-analyze: pipe through SED_PROCESS
On Sat, 22.12.12 10:09, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> To be able to add --version and change python binary.
Looks good! Please commit!
> ---
> Makefile.am| 16 ++-
> src/analyze/systemd-analyze| 294
> -
> src/analyze/systemd-analyze.in | 294
> +
> 3 files changed, 307 insertions(+), 297 deletions(-)
> delete mode 100755 src/analyze/systemd-analyze
> create mode 100755 src/analyze/systemd-analyze.in
>
> diff --git a/Makefile.am b/Makefile.am
> index 429da59..7c12e40 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -225,9 +225,6 @@ bin_PROGRAMS = \
> systemd-detect-virt \
> systemd-delta
>
> -dist_bin_SCRIPTS = \
> - src/analyze/systemd-analyze
> -
> rootlibexec_PROGRAMS = \
> systemd \
> systemd-cgroups-agent \
> @@ -253,6 +250,15 @@ systemgenerator_PROGRAMS = \
> systemd-fstab-generator \
> systemd-system-update-generator
>
> +dist_bin_SCRIPTS = \
> + src/analyze/systemd-analyze
> +
> +EXTRA_DIST += \
> + src/analyze/systemd-analyze.in
> +
> +CLEANFILES += \
> + src/analyze/systemd-analyze
> +
> dist_bashcompletion_DATA = \
> shell-completion/systemd-bash-completion.sh
>
> @@ -3870,6 +3876,10 @@ src/%.policy.in: src/%.policy.in.in Makefile
> $(SED_PROCESS)
> $(AM_V_GEN)chmod +x $@
>
> +src/analyze/systemd-analyze: %: %.in Makefile
> + $(SED_PROCESS)
> + $(AM_V_GEN)chmod +x $@
> +
> src/%.c: src/%.gperf
> $(AM_V_at)$(MKDIR_P) $(dir $@)
> $(AM_V_GEN)$(GPERF) < $< > $@
> diff --git a/src/analyze/systemd-analyze b/src/analyze/systemd-analyze
> deleted file mode 100755
> index 88699d6..000
> --- a/src/analyze/systemd-analyze
> +++ /dev/null
> @@ -1,294 +0,0 @@
> -#!/usr/bin/python
> -
> -import sys, os
> -import argparse
> -from gi.repository import Gio
> -try:
> -import cairo
> -except ImportError:
> -cairo = None
> -
> -def acquire_time_data():
> -manager = Gio.DBusProxy.new_for_bus_sync(bus,
> Gio.DBusProxyFlags.NONE,
> -None, 'org.freedesktop.systemd1',
> '/org/freedesktop/systemd1', 'org.freedesktop.systemd1.Manager', None)
> -units = manager.ListUnits()
> -
> -l = []
> -
> -for i in units:
> -if i[5] != "":
> -continue
> -
> -properties = Gio.DBusProxy.new_for_bus_sync(bus,
> Gio.DBusProxyFlags.NONE,
> -None, 'org.freedesktop.systemd1', i[6],
> 'org.freedesktop.DBus.Properties', None)
> -
> -ixt = properties.Get('(ss)',
> 'org.freedesktop.systemd1.Unit', 'InactiveExitTimestampMonotonic')
> -aet = properties.Get('(ss)',
> 'org.freedesktop.systemd1.Unit', 'ActiveEnterTimestampMonotonic')
> -axt = properties.Get('(ss)',
> 'org.freedesktop.systemd1.Unit', 'ActiveExitTimestampMonotonic')
> -iet = properties.Get('(ss)',
> 'org.freedesktop.systemd1.Unit', 'InactiveEnterTimestampMonotonic')
> -
> -l.append((str(i[0]), ixt, aet, axt, iet))
> -
> -return l
> -
> -def acquire_start_time():
> -properties = Gio.DBusProxy.new_for_bus_sync(bus,
> Gio.DBusProxyFlags.NONE,
> -None, 'org.freedesktop.systemd1',
> '/org/freedesktop/systemd1', 'org.freedesktop.DBus.Properties', None)
> -
> -initrd_time = properties.Get('(ss)',
> 'org.freedesktop.systemd1.Manager', 'InitRDTimestampMonotonic')
> -userspace_time = properties.Get('(ss)',
> 'org.freedesktop.systemd1.Manager', 'UserspaceTimestampMonotonic')
> -finish_time = properties.Get('(ss)',
> 'org.freedesktop.systemd1.Manager', 'FinishTimestampMonotonic')
> -
> -if finish_time == 0:
> -sys.stderr.write("Bootup is not yet finished. Please try
> again later.\n")
> -sys.exit(1)
> -
> -assert initrd_time <= userspace_time
> -assert userspace_time <= finish_time
> -
> -return initrd_time, userspace_time, finish_time
> -
> -def draw_box(context, j, k, l, m, r = 0, g = 0, b = 0):
> -context.save()
> -context.set_source_rgb(r, g, b)
> -context.rectangle(j, k, l, m)
> -context.fill()
> -context.restore()
> -
> -def draw_text(context, x, y, text, size = 12, r = 0, g = 0, b = 0, vcenter =
> 0.5, hcenter = 0.5):
> -context.save()
> -
> -context.set_source_rgb(r, g, b)
> -context.select_font_face("Sans", cairo.FONT_SLANT_NORMAL,
> cairo.FONT_WEIGHT_NORMAL)
> -context.set_font_size(size)
> -
> -if vcenter or hcenter:
> -x_bearing, y_bearing, width, height =
> context.text_extents(text)[:4]
> -
> -if hcenter:
> -x = x - width*hcenter - x_bearing
> -
> -if vcenter:
> -y = y - height*vcenter - y_bearing
> -
> -c
Re: [systemd-devel] [RFC PATCH 1/3] systemd-analyze: pipe through SED_PROCESS
On Fri, 04.01.13 15:15, Lennart Poettering (lenn...@poettering.net) wrote: > On Sat, 22.12.12 10:09, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > To be able to add --version and change python binary. > > Looks good! Please commit! All three patches that is. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC]logind: set locale in user sessions
Lennart Poettering (lenn...@poettering.net) said: > Bill Nottingham (nott...@redhat.com) said: > > > I am tempted to just merge the patch. The discussion on xdg-devel can > > > happen after we commited the code. In fact, moving that to PAM upstream > > > can happen at a later point too, if it is desirable... > > > > > > Also, given that this code is a NOP if ~/.config/locale.conf doesn't > > > exist I think this is relatively straightforward to adopt... > > > > > > Anybody else has opinions on this? Kay, Michal? Otherwise I'll just > > > merge it... Tom. can you bring standardization of ~/.config/locale.conf > > > up on xdg-devel? > > > > FWIW, GNOME stores this in the accounts service, outside of the user's > > configuration heirarchy entirely, for access from the display manager and > > other mechanisms. > > Does gdm actually use that? Old versions used to have a language > drop-down box. But I don't think new versions still have that? > > It might indeed be a good idea to be able to determine the user locale > without having to log-in/mount the home directory. Dunno. > > /me doesn't know anymore what to do... CC'ing Bastien - I believe he's aware of which of GDM and the shell use this setting and how. Bill ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC]logind: set locale in user sessions
On Thu, 2013-01-03 at 23:56 +0100, Lennart Poettering wrote: > It might indeed be a good idea to be able to determine the user locale > without having to log-in/mount the home directory. Dunno. Right, as well as things like the user's picture, hence the reason accountsservice exists. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC]logind: set locale in user sessions
On Fri, 2013-01-04 at 11:23 -0500, Bill Nottingham wrote: > Lennart Poettering (lenn...@poettering.net) said: > > Bill Nottingham (nott...@redhat.com) said: > > > > I am tempted to just merge the patch. The discussion on xdg-devel can > > > > happen after we commited the code. In fact, moving that to PAM upstream > > > > can happen at a later point too, if it is desirable... > > > > > > > > Also, given that this code is a NOP if ~/.config/locale.conf doesn't > > > > exist I think this is relatively straightforward to adopt... > > > > > > > > Anybody else has opinions on this? Kay, Michal? Otherwise I'll just > > > > merge it... Tom. can you bring standardization of ~/.config/locale.conf > > > > up on xdg-devel? > > > > > > FWIW, GNOME stores this in the accounts service, outside of the user's > > > configuration heirarchy entirely, for access from the display manager and > > > other mechanisms. > > > > Does gdm actually use that? Old versions used to have a language > > drop-down box. But I don't think new versions still have that? It's necessary to have that outside the user's config option to allow gdm to read it to set the upcoming session's locale, allow other users to see the languages used by others (used in the Region & Language panel, where the other users' languages are prominent choices), and allow changing the user's language by the system administration tools (used in the User Accounts panel). > > It might indeed be a good idea to be able to determine the user locale > > without having to log-in/mount the home directory. Dunno. > > > > /me doesn't know anymore what to do... > > CC'ing Bastien - I believe he's aware of which of GDM and the shell use this > setting and how. > > Bill ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sometimes systemd takes a very long time to restart service
On Thu, Jan 03, 2013 at 01:41:57PM -0700, JB wrote: > Zbigniew Jędrzejewski-Szmek wrote: > >On Wed, Jan 02, 2013 at 02:28:19AM -0700, JB wrote: > >>Andrey Borzenkov wrote: > >>>В Tue, 01 Jan 2013 23:37:56 -0700 > >>>JB пишет: > Andrey Borzenkov wrote: > >В Tue, 01 Jan 2013 18:52:38 -0700 > >JB пишет: > >>Thanks! I'll try and it may work in my case. What's > >>interesting is that in your case it sounded like rsyslog was > >>hanging around while it was having problems dealing with the > >>condition of having the network unavailable. In my case, > >>webrickd actually stops and shuts down almost immediately > >>but for some reason systemd doesn't or can't figure that > >>out. > >Showing "systemctl status webrickd.service" before restarting and > >during restart may give some hints. > Good idea. > > It goes from active/running to this immediately after restart... > > webrickd.service - Configuration ruby webrick daemon > Loaded: loaded (/etc/systemd/system/webrickd.service) > Active: deactivating (final-sigterm) since Tue, 01 Jan > 2013 22:44:39 -0700; 1min 14s ago > Process: 15771 > ExecStart=/home/rtuser/app/bin/webrickd.rb -d -p > /home/rtuser/app/data/logs/webrickd.pid (code=exited, > status=0/SUCCESS) > > Then this, anywhere from 1 to 3 minutes later... > > webrickd.service - Configuration ruby webrick daemon > Loaded: loaded (/etc/systemd/system/webrickd.service) > Active: active (running) since Tue, 01 Jan 2013 > 22:47:40 -0700; 15s ago > Process: 15807 > ExecStart=/home/rtuser/app/bin/webrickd.rb -d -p > /home/rtuser/app/data/logs/webrickd.pid (code=exited, > status=0/SUCCESS) > >>>And initial state (i.e. after it is started)? > >>> > Any ideas why it sits in state "deactivating (final-sigterm)" > for 1 to 3 minutes > >>It gets better. I took a very stripped simple daemon to try to > >>understand the interaction between systemd and the process. Here it > >>is: > >Hi, > >your process is forking as it should (as least on my machine). ^not (arghhh!) > >Putting systemd in debug mode sudo kill -SIGRTMIN+22 1 > >and running > >sudo systemctl start webrickd.service > >gives me: > >Jan 02 08:55:27 spora sudo[20648]: zbyszek : TTY=pts/0 ; > >PWD=/home/zbyszek/src/systemd ; USER=root ; COMMAND=/bin/systemctl start > >webrickd.service > >Jan 02 08:55:27 spora systemd[1]: Accepted connection on private bus. > >Jan 02 08:55:27 spora systemd[1]: Running GC... > >Jan 02 08:55:27 spora systemd[1]: Got D-Bus request: > >org.freedesktop.systemd1.Manager.StartUnit() on /org/freedesktop/systemd1 > >Jan 02 08:55:27 spora systemd[1]: Trying to enqueue job > >webrickd.service/start/replace > >Jan 02 08:55:27 spora systemd[1]: Installed new job webrickd.service/start > >as 2851 > >Jan 02 08:55:27 spora systemd[1]: Enqueued job webrickd.service/start as 2851 > >Jan 02 08:55:27 spora systemd[1]: About to execute: /usr/bin/ruby > >/home/zbyszek/src/systemd/test.rb > >Jan 02 08:55:27 spora systemd[1]: Forked /usr/bin/ruby as 20651 > >Jan 02 08:55:27 spora systemd[1]: webrickd.service changed failed -> start > >Jan 02 08:55:27 spora systemd[1]: Got D-Bus request: > >org.freedesktop.systemd1.Manager.GetUnit() on /org/freedesktop/systemd1 > >Jan 02 08:55:27 spora systemd[1]: Got D-Bus request: > >org.freedesktop.DBus.Properties.Get() on > >/org/freedesktop/systemd1/unit/webrickd_2eservice > >Jan 02 08:55:27 spora systemd[1]: Received SIGCHLD from PID 20651 (ruby). > >Jan 02 08:55:27 spora systemd[1]: Got SIGCHLD for process 20651 (ruby) > >Jan 02 08:55:27 spora systemd[1]: Child 20651 died (code=exited, > >status=0/SUCCESS) > >Jan 02 08:55:27 spora systemd[1]: Child 20651 belongs to webrickd.service > >Jan 02 08:55:27 spora systemd[1]: webrickd.service: control process exited, > >code=exited status=0 > >Jan 02 08:55:27 spora systemd[1]: webrickd.service got final SIGCHLD for > >state start > >Jan 02 08:55:27 spora systemd[1]: Main PID guessed: 20653 > >Jan 02 08:55:27 spora systemd[1]: webrickd.service changed start -> running > >Jan 02 08:55:27 spora systemd[1]: Job webrickd.service/start finished, > >result=done > >Jan 02 08:55:27 spora systemd[1]: Got D-Bus request: > >org.freedesktop.DBus.Local.Disconnected() on /org/freedesktop/DBus/Local > >Jan 02 08:55:27 spora systemd[1]: Received SIGCHLD from PID 20653 (ruby). > >Jan 02 08:55:27 spora systemd[1]: Got SIGCHLD for process 20653 (ruby) > >Jan 02 08:55:27 spora systemd[1]: Child 20653 died (code=exited, > >status=0/SUCCESS) > >Jan 02 08:55:27 spora systemd[1]: Child 20653 belongs to webrickd.service > >Jan 02 08:55:27 spora systemd[1]: webrickd.service: main process exited, > >code=exited, status=0 > >Jan 02 08:55:27 spora systemd[1]: webrickd.service changed running -> > >stop-sigterm > >Jan 02 08:55:27 spora systemd[1]: Recei
Re: [systemd-devel] sometimes systemd takes a very long time to restart service
Zbigniew Jędrzejewski-Szmek wrote: It gets better. I took a very stripped simple daemon to try to understand the interaction between systemd and the process. Here it is: Hi, your process is forking as it should (as least on my machine). ^not (arghhh!) Figured that's what you meant after reading your comments. I'm using whatever comes with FC15. According to the log it's version 26 (RPM is 26-18) Oh, this is really really old. Please retest with latest FC. If only it were that simple. Unfortunately using the latest FC is simply not an option with this application. It relies up on RTAI lxrt userspace realtime computation system. Currently RTAI only provides a 64-bit patch for 2.6.38.8 kernel. I've tried running that kernel on FC17 and FC16 without success so I need to make this work. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] shutdown umount order
Hi list. On shutdown I have Buffer I/O error on device dm-... because the truecrypt disk is unmounted later than the usb disk containing the truecrypt image. I think this happens, because 1) systemd can't figure out the correct mount dependencies 2) umount is called with the force flag - There are workarounds specially for truecrypt, but why not solve the problem entirely? 1) I think the mount dependencies can't be made 100% reliable. systemd should use the combination of them and /proc/mounts, but only as a HINT In my case /proc/mounts contains the right order. 2) Instead of force umount, systemd should first try to umount everything gracefully, and if at least one mount point was unmounted successfully, then retry. Only if all mounts are busy, systemd should force umount the first candidate and then repeat the graceful umount for others. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] localectl: support systems without locale-archive
Not all systems ships with locales inside /usr/lib/locale-archive, some
prefer to have locale data as individual subdirectories of /usr/lib/locale.
(A notable example of this is OpenEmbeddded, and OSes deriving from it
like gnome-ostree).
Given that glibc supports both ways, localectl should too.
---
src/locale/localectl.c | 101 +
1 file changed, 85 insertions(+), 16 deletions(-)
diff --git a/src/locale/localectl.c b/src/locale/localectl.c
index 383a17d..fbb3bb6 100644
--- a/src/locale/localectl.c
+++ b/src/locale/localectl.c
@@ -266,7 +266,7 @@ finish:
return r;
}
-static int list_locales(DBusConnection *bus, char **args, unsigned n) {
+static int add_locales_from_archive(Set *locales) {
/* Stolen from glibc... */
struct locarhead {
@@ -304,21 +304,15 @@ static int list_locales(DBusConnection *bus, char **args,
unsigned n) {
const struct namehashent *e;
const void *p = MAP_FAILED;
_cleanup_close_ int fd = -1;
-_cleanup_strv_free_ char **l = NULL;
-char **j;
-Set *locales;
size_t sz = 0;
struct stat st;
unsigned i;
int r;
-locales = set_new(string_hash_func, string_compare_func);
-if (!locales)
-return log_oom();
-
fd = open("/usr/lib/locale/locale-archive",
O_RDONLY|O_NOCTTY|O_CLOEXEC);
if (fd < 0) {
-log_error("Failed to open locale archive: %m");
+if (errno != ENOENT)
+log_error("Failed to open locale archive: %m");
r = -errno;
goto finish;
}
@@ -380,15 +374,93 @@ static int list_locales(DBusConnection *bus, char **args,
unsigned n) {
}
}
+r = 0;
+
+ finish:
+if (p != MAP_FAILED)
+munmap((void*) p, sz);
+
+return r;
+}
+
+static int add_locales_from_libdir (Set *locales) {
+DIR *dir;
+struct dirent *entry;
+int r;
+
+dir = opendir("/usr/lib/locale");
+if (!dir) {
+log_error("Failed to open locale directory: %m");
+r = -errno;
+goto finish;
+}
+
+errno = 0;
+while ((entry = readdir(dir))) {
+char *z;
+
+if (entry->d_type != DT_DIR)
+continue;
+
+if (ignore_file(entry->d_name))
+continue;
+
+z = strdup(entry->d_name);
+if (!z) {
+r = log_oom();
+goto finish;
+}
+
+r = set_put(locales, z);
+if (r < 0) {
+free(z);
+
+if (r != -EEXIST) {
+log_error("Failed to add locale: %s",
strerror(-r));
+goto finish;
+}
+}
+
+errno = 0;
+}
+
+if (errno != 0) {
+log_error("Failed to read locale directory: %m");
+r = -errno;
+goto finish;
+}
+
+r = 0;
+
+ finish:
+closedir(dir);
+return r;
+}
+
+static int list_locales(DBusConnection *bus, char **args, unsigned n) {
+Set *locales;
+_cleanup_strv_free_ char **l = NULL;
+char **j;
+int r;
+
+locales = set_new(string_hash_func, string_compare_func);
+if (!locales)
+return log_oom();
+
+r = add_locales_from_archive(locales);
+if (r < 0 && r != -ENOENT)
+goto finish;
+
+r = add_locales_from_libdir(locales);
+if (r < 0)
+goto finish;
+
l = set_get_strv(locales);
if (!l) {
r = log_oom();
goto finish;
}
-set_free(locales);
-locales = NULL;
-
strv_sort(l);
pager_open_if_enabled();
@@ -399,10 +471,7 @@ static int list_locales(DBusConnection *bus, char **args,
unsigned n) {
r = 0;
finish:
-if (p != MAP_FAILED)
-munmap((void*) p, sz);
-
-set_free_free(locales);
+set_free(locales);
return r;
}
--
1.8.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] shutdown umount order
On Sat, Jan 05, 2013 at 02:22:11AM +0400, Ilya Basin wrote: > Hi list. > On shutdown I have >Buffer I/O error on device dm-... > because the truecrypt disk is unmounted later than the usb disk > containing the truecrypt image. > I think this happens, because > 1) systemd can't figure out the correct mount dependencies > 2) umount is called with the force flag > - > There are workarounds specially for truecrypt, but why not solve the > problem entirely? > > 1) I think the mount dependencies can't be made 100% reliable. systemd > should use the combination of them and /proc/mounts, but only as a HINT > In my case /proc/mounts contains the right order. No, /proc/mounts does not contain this information. /proc/self/mountinfo contains sufficient data to reconstruct the mount hierarchy, but still falls short when you introduce loop devices -- backing files are not considered anywhere, as you're seeing. To fix this properly requires fixing the kernel, not systemd. Feel free to override your own mount unit and add the extra dependency on the USB disk. Then, systemd will do the right thing. > 2) Instead of force umount, systemd should first try to umount > everything gracefully, and if at least one mount point was unmounted > successfully, then retry. > Only if all mounts are busy, systemd should force umount the first > candidate and then repeat the graceful umount for others. MNT_FORCE is only effective with NFS mounts. It has no effect otherwise. Cheers, Dave ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Native systemd FUSE mounts don't umount on exit
At Pantheon, we've noticed that systemd uses OS data on whether something is mounted even if it's a native .mount unit. We'd like to see better mount supervision by systemd and automatic umount-ing on failure. For FUSE mounts, if the supervised process fails, the mount is dead, even if the FUSE process didn't cleanly umount it on exit. systemd ought to know that a mount is a oneshot vs. a forking type and mark the mount "failed" if it is forking. Obviously, this is a divergence from what's supported in fstab, but there's no other way for systemd to know whether a mount is behaving properly. systemd also doesn't cleanly kill everything in the cgroup on stop/restart of the mount. We occasionally end up with multiple processes in the cgroup from various mount attempts, even attempts from different versions of the .mount unit. This creates many problems for FUSE-based file systems expecting to manage PID files or needing exclusive access to cache directories. It'd be great to even add "notify" support to mounts so they can report back health, as a service does. Should we just be using services instead? It seems like all of these things would be useful for FUSE-based file systems that keep (and require) a process to persist. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Native systemd FUSE mounts don't umount on exit
On Sat, Jan 5, 2013 at 1:11 PM, David Strauss wrote: > Should we just be using services instead? Actually, we can't just do that, as systemd's automount support requires the mounting commands to be in fstab or a .mount unit. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
