Re: [systemd-devel] [RFC PATCH] Fix so install will work without 'ln --relative' support
Hi,
Please review the patch and let us know if anything needs to be
changed. It would be nice if we can get this in before 213.
Umut
On Wed, May 7, 2014 at 8:54 AM, Emil Sjölin emil.sjo...@axis.com wrote:
This fix makes sure that the package installation will work
on systems using versions of 'GNU coreutils' older than 8.16.
Please see tools/lnr.sh for limitations for this fix.
---
configure.ac | 16 ++
tools/lnr.sh | 93
++
2 files changed, 109 insertions(+)
create mode 100755 tools/lnr.sh
diff --git a/configure.ac b/configure.ac
index ead697b..399a52f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -315,6 +315,22 @@ fi
AM_CONDITIONAL(ENABLE_COVERAGE, [test $have_coverage = yes])
#
--
+ln_relative_support=yes
+AC_CHECK_PROG(ln_found, [ln], [yes], [no])
+if test x$ln_found = xno ; then
+AC_MSG_ERROR([*** ln support requested but the program was not
found])
+else
+ln_version_major=`ln --version | head -1 | cut -d ' ' -f 4 | cut -d
'.' -f 1`
+ln_version_minor=`ln --version | head -1 | cut -d ' ' -f 4 | cut -d
'.' -f 2`
+if test $ln_version_major -lt 8 || test $ln_version_major -eq 8
-a $ln_version_minor -lt 16; then
+ln_relative_support=no
+fi
+if test x$ln_relative_support = xno; then
+LN_S=$(echo $LN_S | sed s:ln:$srcdir\/tools\/lnr.sh:)
+fi
+fi
+
+#
--
have_kmod=no
AC_ARG_ENABLE(kmod, AS_HELP_STRING([--disable-kmod], [disable loadable
modules support]))
if test x$enable_kmod != xno; then
diff --git a/tools/lnr.sh b/tools/lnr.sh
new file mode 100755
index 000..74e1644
--- /dev/null
+++ b/tools/lnr.sh
@@ -0,0 +1,93 @@
+# This script makes the 'ln --relative' command work as expected on a system
where the
+# 'relative' option of 'ln' is not supported.
+#
+# NOTE:
+# The script assumes that the 'relative' option of 'ln' is used with any
+# of the following syntaxes:
+# '--relative'
+# '-r'
+#
+# The script will NOT handle combined options e.g. '-rf', '-ir' etc.
+# The script will also only handle the 1st form of the 'ln' command (see man
page
+# for the 'ln' command for the different forms).
+#
+
+
+relative_file() {
+ # Calculate the relative path from $1 to $2.
+ # $1 and $2 are files (including paths).
+
+ source=$(dirname $1)
+ target=$(dirname $2)
+
+ # Make the paths absolute
+ [ ${source#/} != $source ] || source=$(pwd)/$source
+ [ ${target#/} != $target ] || target=$(pwd)/$target
+
+ common_part=$source
+ result=
+
+ while [ ${target#$common_part} = ${target} ]; do
+ # No match, means that the candidate common part is not
correct
+ # Go up one level (reduce common part)
+ common_part=$(dirname $common_part)
+ # and record that we went back, with correct / handling
+ if [ -z $result ]; then
+ result=..
+ else
+ result=../$result
+ fi
+ done
+
+ if [ $common_part = / ]; then
+ # Special case for root (no common path)
+ result=$result/
+ fi
+
+ # Since we now have identified the common part,compute the non-common
+ # part
+ forward_part=${target#$common_part}
+
+ # And now stick all parts together
+ result=$result$forward_part
+ result=${result%/}
+ result=$result/$(basename $2)
+ result=${result#/}
+
+ echo $result
+}
+
+
+# relative options
+relop_1=--relative
+relop_2=-r
+
+# indicates if the relative option is used
+relative_option=no
+
+# the new command line
+new_cmd=ln
+
+while [ $# -gt 2 ]; do
+ string=$1
+ if [ ${string#-*} != $string ]; then
+ # argument is an option
+ if [ $string = $relop_1 ] || [ $string = $relop_2 ];
then
+ relative_option=yes
+ else
+ # add option to new command line
+ new_cmd=$new_cmd $string
+ fi
+ fi
+ shift
+done
+
+if [ $relative_option = yes ]; then
+ new_cmd=$new_cmd $(relative_file $2 $1) $2
+else
+ new_cmd=$new_cmd $1 $2
+fi
+
+eval $new_cmd
+
+exit 0
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
On Wed, May 14, 2014 at 1:05 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Umut Tezduyar Lindskog at 13/05/14 18:37 did gyre and gimble: On Wednesday, May 7, 2014, Colin Guthrie gm...@colin.guthr.ie mailto:gm...@colin.guthr.ie wrote: 'Twas brillig, and Umut Tezduyar Lindskog at 04/03/14 12:44 did gyre and gimble: Does that actually matter much? This ln usage is at build time, not install time, and those stable versions aren't going to upgrade to a current systemd, because avoiding non-minimal upgrades is the whole point of stable distro releases. As you have stated, it matters for build time and we have build machines not running the latest and greatest SW. I wouldn't be surprised if we are not alone. Yeah, some of our build nodes are actually pretty old too, but that shouldn't matter really as the building happens inside a chroot with the latest packages, which includes latest ln. Do you really build on an older node against older libs with older ln etc? I would have thought you'd also have some kind of chroot on these nodes when building too no? No. We just have virtual machines with Debian Wheezy to do the build. Forgive my ignorance, but I'm curious as to how that works now :) No worries. So the build runs on an older distro, but it's built *for* newer versions of the distro (I don't recall all the Debian names, so I'd have to look up exactly how old Wheezy is...) - is that correct? We are cross compiling for our own distro. Our build machines which execute the programs to do the build are Debian stable. Umut Assuming that's right, how do you deal with linking against older system libraries etc when building the package? If you do not install all the new deps (and buildchain) in a chroot, how are they installed and made available to the compiler? Are they just installed somehow relocated and passed in as compile time options (i.e. overriding the pkgconfig path etc.) Thanks! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On Thu, May 15, 2014 at 2:30 AM, Andy Kittner andy.kitt...@gmail.com wrote: On 14/05/14 18:33, Lennart Poettering wrote: On Tue, 13.05.14 20:01, Andy Kittner (andy.kitt...@gmail.com) wrote: | May 13 18:50:33 pinky systemd-udevd[2751]: conflicting device node '/dev/mapper/swap' found, link to '/dev/dm-1' will not be created Thats the first one I find a bit fishy, but it doesn't sound fatal either... This really looks as if you built the DM userspace stuff without udev support. File a bug against you distro. That should not be the case, the udev useflag is enabled across the board and I just double-checked cryptsetup, libdevmapper and dmsetup with ldd; all are linked against libudev. Is there anything else I could/should check? Are you running an initrd without udev, and/or tools that mess around with mknod in /dev? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd freezes after rshd execution, if network connection is down
Now I've tested it, and it fixed the problem :)
Thanks,
Jimmy
On Tue, May 13, 2014 at 11:31 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Tue, May 13, 2014 at 07:40:53PM +0200, Umut Tezduyar Lindskog wrote:
It is also reproducible by just loosing the carrier on the link. Maybe new
async close is a candidate to solve it.
On Tuesday, April 29, 2014, Harald Hoyer harald.ho...@gmail.com wrote:
Am 28.04.2014 13:33, schrieb Jimmy Assarsson:
Hi,
We stumbled upon a freeze/block in systemd.
The problem occurs when a rshd (socket activated) execution is
completed, the network connection is down and systemd is closing the
socket.
This causes a long (60 seconds) freeze where it's not possible to
communicate with systemd.
Do you have any idea on what is causing this or how we can investigate
this further?
Can you check if this patch fixes the problem:
--
Subject: [PATCH] core: close socket fds asynchronously
http://lists.freedesktop.org/archives/systemd-devel/2014-April/018928.html
---
src/core/service.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/core/service.c b/src/core/service.c
index 694a265..7461ec3 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -27,6 +27,7 @@
#include linux/reboot.h
#include sys/syscall.h
+#include async.h
#include manager.h
#include unit.h
#include service.h
@@ -222,7 +223,7 @@ static void service_close_socket_fd(Service *s) {
if (s-socket_fd 0)
return;
-s-socket_fd = safe_close(s-socket_fd);
+s-socket_fd = asynchronous_close(s-socket_fd);
}
static void service_connection_unref(Service *s) {
@@ -2705,7 +2706,7 @@ static int service_deserialize_item(Unit *u, const char
*key, const char *value,
log_debug_unit(u-id, Failed to parse socket-fd
value %s, value);
else {
-safe_close(s-socket_fd);
+asynchronous_close(s-socket_fd);
s-socket_fd = fdset_remove(fds, fd);
}
} else if (streq(key, main-exec-status-pid)) {
--
1.9.0
--
Thanks,
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On 15/05/14 10:16, Kay Sievers wrote: Are you running an initrd without udev, and/or tools that mess around with mknod in /dev? No, the initrd uses udev and is created by copying cryptsetup etc. including all dependent libraries from the host system. I recreated it yesterday, so there are the using the exact same versions. I also ran the initrd with the debug flag where it puts you in a debug shell at various points. Right before switching to the new root ( the /dev etc. mounts have been moved to /newroot already at this point) the only nodes I have in /newroot/dev/mapper are control root - root_sdb5-root root_sdb5-root - ../dm-0 Hmm, if I have some time tonight I think I'll try real_init=/bin/bash and see what happens if I fire up things manually Regards, Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Start-up resource and prioritization control
Hi Umut, Sorry for digging out an old thread, but it appears it has not yet been answered. On Thu, Apr 24, 2014 at 11:15 AM, Umut Tezduyar Lindskog u...@tezduyar.com wrote: We are starting many services between basic.target - multi-user.target at the same time and due to this we are suffering from following two subjects. What can we do to overcome these problems? 1) We would like to start a subset of services that are scheduled to start between basic.target - multi-user.target before the rest and there is no built in way to satisfy our needs. The reason for this is purely scheduling, right? I looked at this sort of thing in the past (and noticed that such tweaks could indeed give quite noticeable performance benefits), however, we discussed this and I was convinced that we should not try to play such games in systemd, rather we should let the kernel do the scheduling and possibly provide it some hints (see below). a) We could use Before=, After= on services but the downside of this kind of dependency is we have to edit every single service file with Before=, After= directive. This is not the best option when the subset of services we would like to start early might change between hardware or product configuration. That approach would probably work, but I agree it is a hack... b) The ongoing patch http://lists.freedesktop.org/archives/systemd-devel/2014-March/018220.html is promising but it seems to be stopped. Any reason? Looks like the correct approach to me. Not sure what's going on with it though (if anything). c) A service running before basic.target and queriying systemd with systemctl show -p [Wants Requires] default.target and adding Before=, After= dependency on services on runtime. Doesn't seem so efficient. Might also work as a temporary hack, but long-term we'd hopefully get b)... 2) Due to starting too many services and due to having frequent context switches (flushing of caches), we see that boot time is longer than booting services sequentially. a) Proposing a configuration to limit the number of jobs that are in activating state. Wouldn't thes easily deadlock? Imagine you have two services on your system A and B. Each of them needs to communicate with the other it would become fully active. If your limit of active jobs is 2 there is no problem, but if it is 1 it would always deadlock... b) nice value of the services can be changed to prioritize things randomly but then we have to revert back the nice value once the boot is completed. Doesn't seem so easy. This is basically the same as your 1.b) right? It is just a matter of setting the right sorts of scheduling priority during startup... We are aware that our problem is mostly embedded platform specific. We could solve our problem staticly with what systemd offers but a static solution that is customized for one hardware is not the best solution for another hardware. Having static solutions per hardware is extremely hard to maintain and we would like to solve this problem upstream instead of downstream magic. I think this sounds universally useful, and it would be cool if we could get the startup resource logic upstream... Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] remounting root fs outside containers as MS_SHARED
On Wed, 14.05.14 15:12, Ani Sinha (a...@arista.com) wrote: On Wed, May 14, 2014 at 9:14 AM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 13.05.14 20:16, Ani Sinha (a...@arista.com) wrote: Why precisely would you want to disable propagation from the root dir? The core issue is that pivot_root() syscall breaks if the new_root is a mount point under / which is now shared. We use pivot_root() in our chroot code. How do you propose softwares fix that? Note that systemd itself can do pivot_root() for you. See systemctl switch-root. Isn't that enough for your needs? If not, please have a look how it is implemented in systemd: http://cgit.freedesktop.org/systemd/systemd/tree/src/core/switch-root.c This code temporarily switches back to MS_PRIVATE before the switch, then the systemd invoked afterwards immediately switches back to MS_SHARED again. 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] Fix typos in systemctl manpage
--- man/systemctl.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/man/systemctl.xml b/man/systemctl.xml index 94f2380..29ab95f 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -435,7 +435,7 @@ along with systemd; If not, see http://www.gnu.org/licenses/. safe option to request an immediate reboot. If option--force/option is specified twice for these operations, they will be executed immediately without - terminating any processes or umounting any file + terminating any processes or unmounting any file systems. Warning: specifying option--force/option twice with any of these operations might result in data loss./para @@ -1045,7 +1045,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service activation of the unit, including manual activation. Use this option with care. This honors the option--runtime/option option to only mask temporarily -until the next reoobt of the system./para +until the next reboot of the system./para /listitem /varlistentry @@ -1425,7 +1425,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service refsect2 titleParameter Syntax/title - paraUnit ommands listed above take either a single unit name + paraUnit commands listed above take either a single unit name (designated as replaceableNAME/replaceable), or multiple unit specifications (designated as replaceablePATTERN/replaceable...). In the first case, the -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix typos in systemctl manpage
Applied. Thanks! Tom On Thu, May 15, 2014 at 1:11 PM, Eelco Dolstra eelco.dols...@logicblox.com wrote: --- man/systemctl.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/man/systemctl.xml b/man/systemctl.xml index 94f2380..29ab95f 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -435,7 +435,7 @@ along with systemd; If not, see http://www.gnu.org/licenses/. safe option to request an immediate reboot. If option--force/option is specified twice for these operations, they will be executed immediately without - terminating any processes or umounting any file + terminating any processes or unmounting any file systems. Warning: specifying option--force/option twice with any of these operations might result in data loss./para @@ -1045,7 +1045,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service activation of the unit, including manual activation. Use this option with care. This honors the option--runtime/option option to only mask temporarily -until the next reoobt of the system./para +until the next reboot of the system./para /listitem /varlistentry @@ -1425,7 +1425,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service refsect2 titleParameter Syntax/title - paraUnit ommands listed above take either a single unit name + paraUnit commands listed above take either a single unit name (designated as replaceableNAME/replaceable), or multiple unit specifications (designated as replaceablePATTERN/replaceable...). In the first case, the -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Reset the context of /run/user/UID to the default. Bug #1097901.
---
src/login/logind-user.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index 961cbcb..42946ae 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -337,6 +337,7 @@ static int user_mkdir_runtime_path(User *u) {
}
}
+label_fix(p,false,false);
u-runtime_path = p;
return 0;
@@ -423,7 +424,9 @@ int user_start(User *u) {
log_debug(New user %s logged in., u-name);
/* Make XDG_RUNTIME_DIR */
+label_init(/var/run/user);
r = user_mkdir_runtime_path(u);
+label_finish();
if (r 0)
return r;
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd freezes after rshd execution, if network connection is down
On Thu, May 15, 2014 at 10:40:48AM +0200, Jimmy Assarsson wrote:
Now I've tested it, and it fixed the problem :)
Great, thanks for testing. I'll push it to master then.
Zbyszek
On Tue, May 13, 2014 at 11:31 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Tue, May 13, 2014 at 07:40:53PM +0200, Umut Tezduyar Lindskog wrote:
It is also reproducible by just loosing the carrier on the link. Maybe new
async close is a candidate to solve it.
On Tuesday, April 29, 2014, Harald Hoyer harald.ho...@gmail.com wrote:
Am 28.04.2014 13:33, schrieb Jimmy Assarsson:
Hi,
We stumbled upon a freeze/block in systemd.
The problem occurs when a rshd (socket activated) execution is
completed, the network connection is down and systemd is closing the
socket.
This causes a long (60 seconds) freeze where it's not possible to
communicate with systemd.
Do you have any idea on what is causing this or how we can investigate
this further?
Can you check if this patch fixes the problem:
--
Subject: [PATCH] core: close socket fds asynchronously
http://lists.freedesktop.org/archives/systemd-devel/2014-April/018928.html
---
src/core/service.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/core/service.c b/src/core/service.c
index 694a265..7461ec3 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -27,6 +27,7 @@
#include linux/reboot.h
#include sys/syscall.h
+#include async.h
#include manager.h
#include unit.h
#include service.h
@@ -222,7 +223,7 @@ static void service_close_socket_fd(Service *s) {
if (s-socket_fd 0)
return;
-s-socket_fd = safe_close(s-socket_fd);
+s-socket_fd = asynchronous_close(s-socket_fd);
}
static void service_connection_unref(Service *s) {
@@ -2705,7 +2706,7 @@ static int service_deserialize_item(Unit *u, const
char *key, const char *value,
log_debug_unit(u-id, Failed to parse socket-fd
value %s, value);
else {
-safe_close(s-socket_fd);
+asynchronous_close(s-socket_fd);
s-socket_fd = fdset_remove(fds, fd);
}
} else if (streq(key, main-exec-status-pid)) {
--
1.9.0
--
Thanks,
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] core: add startup resource control option
Similar to CPUShares= and BlockIOWeight= respectively. However only
assign the specified weight during startup. Each control group
attribute is re-assigned as weight by CPUShares=weight and
BlockIOWeight=weight after startup. If not CPUShares= or
BlockIOWeight= be specified, then the attribute is re-assigned to each
default attribute value. (default cpu.shares=1024, blkio.weight=1000)
If only CPUShares=weight or BlockIOWeight=weight be specified, then
that implies StartupCPUShares=weight and StartupBlockIOWeight=weight.
---
man/systemd.resource-control.xml | 24 ++
src/core/cgroup.c | 40 -
src/core/cgroup.h | 8 +++-
src/core/dbus-cgroup.c| 42 ++
src/core/load-fragment-gperf.gperf.m4 | 2 +
src/core/load-fragment.c | 83 +++
src/core/load-fragment.h | 2 +
src/core/manager.c| 16 +++
src/core/manager.h| 3 ++
src/core/unit.c | 18
10 files changed, 226 insertions(+), 12 deletions(-)
diff --git a/man/systemd.resource-control.xml b/man/systemd.resource-control.xml
index 80c365b..33d2f2e 100644
--- a/man/systemd.resource-control.xml
+++ b/man/systemd.resource-control.xml
@@ -171,6 +171,18 @@ along with systemd; If not, see
http://www.gnu.org/licenses/.
/varlistentry
varlistentry
+
termvarnameStartupCPUShares=replaceableweight/replaceable/varname/term
+
+listitem
+ paraSimilar to varnameCPUShares=/varname. However,
+ only be assigned on startup state. After finishing startup, will be
+ re-assigned by varnameCPUShares=/varname. If
+ varnameCPUShares=/varname is not specified, then it will be
+ assigned to default(1024)./para
+/listitem
+ /varlistentry
+
+ varlistentry
termvarnameMemoryAccounting=/varname/term
listitem
@@ -241,6 +253,18 @@ along with systemd; If not, see
http://www.gnu.org/licenses/.
/varlistentry
varlistentry
+
termvarnameStartupBlockIOWeight=replaceableweight/replaceable/varname/term
+
+listitem
+ paraSimilar to varnameBlockIOWeight=/varname. However,
+ only be assigned on startup state. After finishing startup, will be
+ re-assigned by varnameBlockIOWeight=/varname. If
+ varnameBlockIOWeight=/varname is not specified, then it will be
+ assigned to default(1000)./para
+/listitem
+ /varlistentry
+
+ varlistentry
termvarnameBlockIODeviceWeight=replaceabledevice/replaceable
replaceableweight/replaceable/varname/term
listitem
diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 29ab645..80a5575 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -34,8 +34,12 @@ void cgroup_context_init(CGroupContext *c) {
* structure is preinitialized to 0 */
c-cpu_shares = 1024;
+c-startup_cpu_shares = 1024;
+c-startup_cpu_shares_set = false;
c-memory_limit = (uint64_t) -1;
c-blockio_weight = 1000;
+c-startup_blockio_weight = 1000;
+c-startup_blockio_weight_set = false;
c-cpu_quota_per_sec_usec = (usec_t) -1;
c-cpu_quota_usec = (usec_t) -1;
@@ -124,20 +128,24 @@ void cgroup_context_dump(CGroupContext *c, FILE* f, const
char *prefix) {
%sBlockIOAccounting=%s\n
%sMemoryAccounting=%s\n
%sCPUShares=%lu\n
+%sStartupCPUShares=%lu\n
%sCPUQuota=%s\n
%sCPUQuotaPerSecSec=%s\n
%sCPUQuotaPeriodSec=%s\n
%sBlockIOWeight=%lu\n
+%sStartupBlockIOWeight=%lu\n
%sMemoryLimit=% PRIu64 \n
%sDevicePolicy=%s\n,
prefix, yes_no(c-cpu_accounting),
prefix, yes_no(c-blockio_accounting),
prefix, yes_no(c-memory_accounting),
prefix, c-cpu_shares,
+prefix, c-startup_cpu_shares,
prefix, strna(format_timespan(u, sizeof(u),
cgroup_context_get_cpu_quota_usec(c), 1)),
prefix, strna(format_timespan(t, sizeof(t),
cgroup_context_get_cpu_quota_per_sec_usec(c), 1)),
prefix, strna(format_timespan(s, sizeof(s),
c-cpu_quota_period_usec, 1)),
prefix, c-blockio_weight,
+prefix, c-startup_blockio_weight,
prefix, c-memory_limit,
prefix, cgroup_device_policy_to_string(c-device_policy));
@@ -306,7 +314,7 @@ fail:
return -errno;
}
-void cgroup_context_apply(CGroupContext *c, CGroupControllerMask mask, const
char *path) {
+void cgroup_context_apply(Manager *m, CGroupContext *c, CGroupControllerMask
mask, const char *path) {
bool is_root;
int r;
@@ -324,7 +332,9 @@ void
Re: [systemd-devel] [PATCH] core: add startup resource control option
On 05/16/2014 12:09 AM, WaLyong Cho wrote: Similar to CPUShares= and BlockIOWeight= respectively. However only assign the specified weight during startup. Each control group attribute is re-assigned as weight by CPUShares=weight and BlockIOWeight=weight after startup. If not CPUShares= or BlockIOWeight= be specified, then the attribute is re-assigned to each default attribute value. (default cpu.shares=1024, blkio.weight=1000) If only CPUShares=weight or BlockIOWeight=weight be specified, then that implies StartupCPUShares=weight and StartupBlockIOWeight=weight. --- man/systemd.resource-control.xml | 24 ++ src/core/cgroup.c | 40 - src/core/cgroup.h | 8 +++- src/core/dbus-cgroup.c| 42 ++ src/core/load-fragment-gperf.gperf.m4 | 2 + src/core/load-fragment.c | 83 +++ src/core/load-fragment.h | 2 + src/core/manager.c| 16 +++ src/core/manager.h| 3 ++ src/core/unit.c | 18 10 files changed, 226 insertions(+), 12 deletions(-) --- snipped --- Previous my patch looks too old. So I rebase and resolve conflicts with simple test. WaLyong ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Reset the context of /run/user/UID to the default. Bug #1097901.
On Thu, 15.05.14 14:54, Miroslav Grepl (mgr...@redhat.com) wrote:
---
src/login/logind-user.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index 961cbcb..42946ae 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -337,6 +337,7 @@ static int user_mkdir_runtime_path(User *u) {
}
}
+label_fix(p,false,false);
Please follow the use coding style, i.e. spaces after the ,
u-runtime_path = p;
return 0;
@@ -423,7 +424,9 @@ int user_start(User *u) {
log_debug(New user %s logged in., u-name);
/* Make XDG_RUNTIME_DIR */
+label_init(/var/run/user);
This looks incorrect. label_init() will be a NOP the second it is
called, and we already call it in logind, with the /etc prefix, hence
we'll only load an incomplete database for the other invocation...
r = user_mkdir_runtime_path(u);
+label_finish();
if (r 0)
return r;
Why is this necessary, even? I though selinux in the kernel was nowadays
able to take the file name to create into account when applying a label,
so why do we need userspace magic for this?
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] cryptsetup vs. swapon/fsck (some kind of race condition)
On Thu, 15.05.14 02:30, Andy Kittner (andy.kitt...@gmail.com) wrote: On 14/05/14 18:33, Lennart Poettering wrote: On Tue, 13.05.14 20:01, Andy Kittner (andy.kitt...@gmail.com) wrote: | May 13 18:50:33 pinky systemd-udevd[2751]: conflicting device node '/dev/mapper/swap' found, link to '/dev/dm-1' will not be created Thats the first one I find a bit fishy, but it doesn't sound fatal either... This really looks as if you built the DM userspace stuff without udev support. File a bug against you distro. That should not be the case, the udev useflag is enabled across the board and I just double-checked cryptsetup, libdevmapper and dmsetup with ldd; all are linked against libudev. Is there anything else I could/should check? Well, something appears to create your device nodes, and it shouldn't do that... On a udev system userspace never creates any device nodes, that's done on its own by the kernel via devtmpfs, udev then just creates symlinks on top, or changes access rights. It appears that your LVM/DM installation for some reason created device nodes anyway, and you need to figure out why it did that, and turn this off. It might be in your initrd... Further questions regarding LVM/DM should better be directed to the LVM/DM people... 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] inconsistency between hibernate-multiple-sessions and suspend-multiple-sessions
On Thu, 15.05.14 02:35, Michael Biebl (mbi...@gmail.com) wrote: 2014-05-15 2:29 GMT+02:00 Michael Biebl mbi...@gmail.com: What's the reason for this inconsistency? Small correction: org.freedesktop.login1.power-off-multiple-sessions org.freedesktop.login1.reboot-multiple-sessions org.freedesktop.login1.suspend-multiple-sessions → allow_activeyes/allow_active org.freedesktop.login1.hibernate-multiple-sessions → allow_activeauth_admin_keep/allow_active I would actually understand to not allow reboot or poweroff when multiple users are logged in, because the session is gone. Not allowing hibernate is surprising in that regard since the session is restored on resume. Ah, that was merely oversight. We loosened the policies for poweroff/reboot/suspend a bit, and I simply forgot to do the same for hibernation. Fixed. 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] Journal rotation and notifying users
On Wed, 14.05.14 13:03, Colin Guthrie (gm...@colin.guthr.ie) wrote: Hiya, I recently had a rather unfortunate crash on my home system. One of the disks failed and for some reason or another, it logged a lot of data. As I don't have *that* much space for journal files (~800Mb) the logs rotated and when trying to diagnose the crash I was left with very little information. The fact that my journal logs started pretty much the same time as the server died initally made me suspicious that the files had been (maliciously or otherwise) deleted. I wonder if it would be worthwhile to somehow store the last rotation metadata and show it at the beggining of the journalctl output which currently says e.g: -- Logs begin at Tue 2014-05-13 20:09:01 BST, end at Wed 2014-05-14 13:00:05 BST. -- i.e. perhaps it should include details on when the last rotation occured and perhaps why? But how would that information be any different from what is shown now? I mean, everything that is older than the Logs begin at time has been rotated away... Are you suggesting to simply change the text we show there? Logs rotated at... or so? 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] network: fix build failure, missing KMOD_XXX flags
On Tue, 13.05.14 19:35, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: Quite frankly, I'd much rather see the kmod logic remvoed from netword entirely... We shouldn't work around kernel brokeness... Please try to follow the usual identation style of the code, in this case, please always break the words into individual lines in the makefile, like the rest of it... Anyway, commited this now. - Add KMOD_CFLAGS and KMOD_LIBS where appropiate - networkd now requires kmod. make --disable-kmod --enable-networkd to raise an error. --- Makefile.am | 7 ++- configure.ac | 2 ++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index b8ff732..0d08975 100644 --- a/Makefile.am +++ b/Makefile.am @@ -2479,6 +2479,7 @@ busctl_CFLAGS = \ noinst_LTLIBRARIES += \ libsystemd-network.la +libsystemd_network_la_CFLAGS = $(AM_CFLAGS) $(KMOD_CFLAGS) libsystemd_network_la_SOURCES = \ src/systemd/sd-network.h \ src/systemd/sd-dhcp-client.h \ @@ -2504,7 +2505,8 @@ libsystemd_network_la_SOURCES = \ libsystemd_network_la_LIBADD = \ libsystemd-label.la \ libsystemd-internal.la \ - libsystemd-shared.la + libsystemd-shared.la \ + $(KMOD_LIBS) test_dhcp_option_SOURCES = \ src/libsystemd-network/dhcp-protocol.h \ @@ -4185,6 +4187,7 @@ systemd_networkd_LDADD = \ noinst_LTLIBRARIES += \ libsystemd-networkd-core.la +libsystemd_networkd_core_la_CFLAGS = $(AM_CFLAGS) $(KMOD_CFLAGS) libsystemd_networkd_core_la_SOURCES = \ src/libsystemd-network/network-internal.h \ src/network/networkd.h \ @@ -4218,6 +4221,8 @@ GENERAL_ALIASES += \ rootlibexec_PROGRAMS += \ systemd-networkd-wait-online +systemd_networkd_wait_online_CFLAGS = $(AM_CFLAGS) $(KMOD_CFLAGS) + systemd_networkd_wait_online_SOURCES = \ src/libsystemd-network/network-internal.h \ src/network/networkd-wait-online.c \ diff --git a/configure.ac b/configure.ac index 972fc2f..4e78bf8 100644 --- a/configure.ac +++ b/configure.ac @@ -875,6 +875,8 @@ if test x$enable_networkd != xno; then AC_DEFINE(ENABLE_NETWORKD, 1, [Define if networkd support is to be enabled]) have_networkd=yes fi +AS_IF([test x$have_networkd = xyes -a x$have_kmod != xyes], + [AC_MSG_ERROR([networkd requires kmod])]) AM_CONDITIONAL(ENABLE_NETWORKD, [test x$have_networkd = xyes]) # -- 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] Reset the context of /run/user/UID to the default. Bug #1097901.
On 05/15/2014 06:24 PM, Lennart Poettering wrote:
On Thu, 15.05.14 14:54, Miroslav Grepl (mgr...@redhat.com) wrote:
---
src/login/logind-user.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index 961cbcb..42946ae 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -337,6 +337,7 @@ static int user_mkdir_runtime_path(User *u) {
}
}
+label_fix(p,false,false);
Sorry for that.
Please follow the use coding style, i.e. spaces after the ,
u-runtime_path = p;
return 0;
@@ -423,7 +424,9 @@ int user_start(User *u) {
log_debug(New user %s logged in., u-name);
/* Make XDG_RUNTIME_DIR */
+label_init(/var/run/user);
This looks incorrect. label_init() will be a NOP the second it is
called, and we already call it in logind, with the /etc prefix, hence
we'll only load an incomplete database for the other invocation...
Well I thought it too but it was not working without this initialization.
r = user_mkdir_runtime_path(u);
+label_finish();
if (r 0)
return r;
Why is this necessary, even? I though selinux in the kernel was nowadays
able to take the file name to create into account when applying a label,
so why do we need userspace magic for this?
See
https://bugzilla.redhat.com/show_bug.cgi?id=1092059#c0
Lennart
Regards,
Miroslav
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] network: fix build failure, missing KMOD_XXX flags
On Thu, May 15, 2014 at 6:52 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 13.05.14 19:35, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: Quite frankly, I'd much rather see the kmod logic remvoed from netword entirely... We shouldn't work around kernel brokeness... Please try to follow the usual identation style of the code, in this case, please always break the words into individual lines in the makefile, like the rest of it... Anyway, commited this now. FYI: http://www.spinics.net/lists/netdev/msg282252.html. So far no comments. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Reset the context of /run/user/UID to the default. Bug #1097901.
On Thu, 15.05.14 18:54, Miroslav Grepl (mgr...@redhat.com) wrote:
u-runtime_path = p;
return 0;
@@ -423,7 +424,9 @@ int user_start(User *u) {
log_debug(New user %s logged in., u-name);
/* Make XDG_RUNTIME_DIR */
+label_init(/var/run/user);
This looks incorrect. label_init() will be a NOP the second it is
called, and we already call it in logind, with the /etc prefix, hence
we'll only load an incomplete database for the other invocation...
Well I thought it too but it was not working without this
initialization.
Sure, some kind of initialization is needed. However, the database is
loaded statically into the process and once only, then you end up with
an incomplete database where the bits the other place where we need
labelling is missing..
r = user_mkdir_runtime_path(u);
+label_finish();
if (r 0)
return r;
Why is this necessary, even? I though selinux in the kernel was nowadays
able to take the file name to create into account when applying a label,
so why do we need userspace magic for this?
See
https://bugzilla.redhat.com/show_bug.cgi?id=1092059#c0
WHich doesn't explain why the kernel cannot derive this rule on its
own. I though the kernel could take the file/dir name to create into
account nowadays when it is created to find its initial label. But if
the kernel can do that, why do we need to involve userspace still?
I'd really prefer if we could keep userspace-controlled labelling at a
minimum. If you ask me we kinda already do too much of it...
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] RFC/fsck: Allow to specify the fsck repair option in the cmdline
From: Holger Hans Peter Freyther hol...@moiji-mobile.com
Some unattended systems do not have a console attached and entering
the default rescue mode will not be too helpful. Allow to specify
the -y option to attempt to fix all filesystem errors.
Manually verified by downloading an image.gz of e2fsprogs, using
losetup and running systemd-fsck on the loop device and varying
the fsck.repair=preen|yes|no option.
---
man/kernel-command-line.xml | 11 +++
man/systemd-f...@.service.xml | 16
src/fsck/fsck.c | 14 +-
3 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml
index dbfec61..a276b71 100644
--- a/man/kernel-command-line.xml
+++ b/man/kernel-command-line.xml
@@ -193,6 +193,17 @@
/varlistentry
varlistentry
+termvarnamefsck.repair=/varname/term
+
+listitem
+paraParameter understood by
+the file system checker
+services. For details, see
+
citerefentryrefentrytitlesystemd-fsck@.service/refentrytitlemanvolnum8/manvolnum/citerefentry./para
+/listitem
+/varlistentry
+
+varlistentry
termvarnamequotacheck.mode=/varname/term
listitem
diff --git a/man/systemd-f...@.service.xml b/man/systemd-f...@.service.xml
index c653dc5..afd8d9b 100644
--- a/man/systemd-f...@.service.xml
+++ b/man/systemd-f...@.service.xml
@@ -98,6 +98,22 @@
skips any file system
checks./para/listitem
/varlistentry
+
+varlistentry
+termvarnamefsck.repair=/varname/term
+
+listitemparaOne of
+literalpreen/literal,
+literalyes/literal,
+literalno/literal. Controls the
+mode of operation. The default is literal
+preen/literal, and will automatically repair
+problems that can be safely fixed. literalyes
+/literal will answer yes to all questions by
+fsck and literalno/literal will answer no
to
+all questions.
+/para/listitem
+/varlistentry
/variablelist
/refsect1
diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index 5ed837d..594f21e 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -4,6 +4,7 @@
This file is part of systemd.
Copyright 2010 Lennart Poettering
+ Copyright 2014 Holger Hans Peter Freyther
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
@@ -42,6 +43,7 @@
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) {
_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
@@ -85,6 +87,16 @@ static int parse_proc_cmdline_item(const char *key, const
char *value) {
arg_skip = true;
else
log_warning(Invalid fsck.mode= parameter. Ignoring.);
+} else if (streq(key, fsck.repair) value) {
+
+if (streq(value, preen))
+arg_repair = -a;
+else if (streq(value, yes))
+arg_repair = -y;
+else if (streq(value, no))
+arg_repair = -n;
+else
+log_warning(Invalid fsck.repair= parameter.
Ignoring.);
} else if (startswith(key, fsck.))
log_warning(Invalid fsck parameter. Ignoring.);
#ifdef HAVE_SYSV_COMPAT
@@ -303,7 +315,7 @@ int main(int argc, char *argv[]) {
}
cmdline[i++] = /sbin/fsck;
-cmdline[i++] = -a;
+cmdline[i++] = arg_repair;
cmdline[i++] = -T;
cmdline[i++] = -l;
--
1.9.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] remounting root fs outside containers as MS_SHARED
On Thu, May 15, 2014 at 3:25 AM, Lennart Poettering lenn...@poettering.net wrote: How do you propose softwares fix that? Note that systemd itself can do pivot_root() for you. See systemctl switch-root. Isn't that enough for your needs? If not, please have a look how it is implemented in systemd: http://cgit.freedesktop.org/systemd/systemd/tree/src/core/switch-root.c This code temporarily switches back to MS_PRIVATE before the switch, then the systemd invoked afterwards immediately switches back to MS_SHARED again. IMHO, this looks like a hack to me. Was this discussed in the linux kernel mailing list? May be you guys can convince the maintainer of that kernel code to find a more elegant solution? Ani ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] RFC/fsck: Allow to specify the fsck repair option in the cmdline
On Thu, 15.05.14 19:07, Holger Freyther (hol...@freyther.de) wrote: From: Holger Hans Peter Freyther hol...@moiji-mobile.com Some unattended systems do not have a console attached and entering the default rescue mode will not be too helpful. Allow to specify the -y option to attempt to fix all filesystem errors. Hmm, we already unconditionally pass -a to fsck, which should have the desired effect of non-interactively fixing everything. What does your patch add on top of 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] remounting root fs outside containers as MS_SHARED
On Thu, 15.05.14 10:22, Ani Sinha (a...@arista.com) wrote: Note that systemd itself can do pivot_root() for you. See systemctl switch-root. Isn't that enough for your needs? If not, please have a look how it is implemented in systemd: http://cgit.freedesktop.org/systemd/systemd/tree/src/core/switch-root.c This code temporarily switches back to MS_PRIVATE before the switch, then the systemd invoked afterwards immediately switches back to MS_SHARED again. IMHO, this looks like a hack to me. Was this discussed in the linux kernel mailing list? May be you guys can convince the maintainer of that kernel code to find a more elegant solution? Well, the guy in charge for this is Al Viro, and he has never replied to any mail I ever sent to him. He thinks systemd is an abomination and talking to us a waste of time, so I figure we have to live with the work-around... Note that the work-around is not too bad. When the initrd invokes systemctl switch-root the nr of mounted files systems is relatively small, hence the call should not be too inefficient... 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] timed out waiting for device dev-disk-by\x2duuid
On Mon, 12.05.14 20:48, Chris Murphy (li...@colorremedies.com) wrote: Two device Btrfs volume, with one device missing (simulated) will not boot, even with rootflags=degraded set which is currently required to enable Btrfs degraded mounts. Upon reaching a dracut shell after basic.target fails with time out, I can mount -o subvol=root,degraded and exit and continue boot normally with just the single device. The problem seems to be that systemd (udev?) is not finding the volume by uuid for some reason, and therefore not attempting to mount it. But I don't know why it can't find it, or even how the find by uuid mechanism works this early in boot. So I'm not sure if this is a systemd or udev bug, or a dracut, or kernel bug. The problem happens with systemd 208-9.fc20 with kernel 3.11.10-301.fc20, and systemd 212-4.fc21 and kernel 3.15.0-0.rc5.git0.1.fc21. As soon as btrfs reports that a file system is ready, systemd will pick it up. This is handled with the btrfs udev built-in, and invoked via /usr/lib/udev/rules.d/64-btrfs.rules. rootflags has no influence on that, as at that point it is not clear whether the block device will be the once that carries the root file system, or any other file system. Not sure what we should be doing about this. Maybe introduce a new btrfs=degraded switch that acts globally, and influences the udev built-in? Kay? 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] timer: allow user to control activation time of cron-like timers
On Sun, 11.05.14 18:33, Reindl Harald (h.rei...@thelounge.net) wrote: It's ok for one timer, but not for the set of them. In general I'm want to schedule all maintenance tasks to 5 a.m. or lunch break and forget about them. This applies both for distro provided timers an my own that's why anacron don't fire up them at the same time given that you can have on a host 10,20,100 guests *that* below is the solution You can use AccuracySec= for the same thing in systemd. 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] RFC/fsck: Allow to specify the fsck repair option in the cmdline
Lennart Poettering lennart at poettering.net writes: the -y option to attempt to fix all filesystem errors. Hmm, we already unconditionally pass -a to fsck, which should have the desired effect of non-interactively fixing everything. What does your patch add on top of that? fsck.ext4(8) lists: -p Automatically repair (preen) the file system. This option will cause e2fsck to automatically fix any filesystem problems that can be safely fixed without human intervention. -y Assume an answer of `yes' to all questions; allows e2fsck to be used non-interactively. This option may not be specified at the same time as the -n or -p options. To see the difference you could download this[1], gunzip, losetup and fsck with -p and -y. The idea/concern is that we have some remote systems and they generally do not have a serial console. So in case the fs is corrupt the question is what to do. Currently the emergency target would be entered but that will not help our users and not us at all. The best I could think of is to just try to fix whatever is broken and see if the system comes back online. If it doesn't then it needs to be replaced, if it did we might be lucky. cheers holger [1] http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/plain/tests/f_baddir/image. gz ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] list-boots is incorrect, was: lost journal persistence
On May 12, 2014, at 9:58 AM, Chris Murphy li...@colorremedies.com wrote: On May 12, 2014, at 7:06 AM, Kirill Elagin kirela...@gmail.com wrote: Could it be that all the boot ids are actually the same for some reason? I had this issue in a container when systemd was reading boot_id from `/proc/sys/kernel/random/boot_id` and since /proc was bind-mounted, boot_id always was host's boot_id. You can also run `journalctl -F _BOOT_ID` to see a set of all the boot ids recorded in the journal (this must agree with `journalctl --list-boots`. # journalctl --list-boots | wc -l 36 [root@rawhide ~]# journalctl -F _BOOT_ID | wc -l 80 # cat /proc/sys/kernel/random/boot_id 420fa190-e7dd-4cd7-b248-fd62417d7c02 # reboot ### # journalctl --list-boots | wc -l 36 [root@rawhide ~]# journalctl -F _BOOT_ID | wc -l 81 # cat /proc/sys/kernel/random/boot_id 1e0d5346-85cb-477b-9ae2-2cfb53097b97 So there are more boot ID's than there are list-boots, and list-boots doesn't increment while boot ID's do. And neither of these boot id's match any of the boot id's in --list-boots. Deleting the files in /var/log/journal/machineid/ fixes the problem on the Fedora 20 and Fedora Rawhide VMs experiencing this problem. If the files are restored, the problem returns. Yet --verify shows PASS for each log file. So it seems there's some kind of corruption or confusion with these log files. The btrfs filesystem is mounted with autodefrag option, for which there have been some problems with kernel 3.12 and older. But the Rawhide system has only been using 3.14 and 3.15 kernels so if there's still some problem I'm not sure how to isolate it since journalctl --verify seems to think the files are OK. Despite autodefrag enabled, the systemjournal has ~1450 fragments according to filefrag. If I boot from a rescue image so nothing is actively writing to these journal files, and recopy them such that they are each 1 extent only, then reboot the system, the list-boots changes. It actually goes down, from 45 boots to 31 boots, and stays stuck with additional reboots. Whereas BOOT_ID continues to increment as before. So just by copying the log files I get different --list-boot behavior. That's pretty strange. Yes, of course also btrfs check and scrub find no problems with either Fedora 20 or Fedora Rawhide Btrfs file systems this problem is happening on. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] timed out waiting for device dev-disk-by\x2duuid
On Thu, 15.05.14 19:29, Lennart Poettering (lenn...@poettering.net) wrote: On Mon, 12.05.14 20:48, Chris Murphy (li...@colorremedies.com) wrote: Two device Btrfs volume, with one device missing (simulated) will not boot, even with rootflags=degraded set which is currently required to enable Btrfs degraded mounts. Upon reaching a dracut shell after basic.target fails with time out, I can mount -o subvol=root,degraded and exit and continue boot normally with just the single device. The problem seems to be that systemd (udev?) is not finding the volume by uuid for some reason, and therefore not attempting to mount it. But I don't know why it can't find it, or even how the find by uuid mechanism works this early in boot. So I'm not sure if this is a systemd or udev bug, or a dracut, or kernel bug. The problem happens with systemd 208-9.fc20 with kernel 3.11.10-301.fc20, and systemd 212-4.fc21 and kernel 3.15.0-0.rc5.git0.1.fc21. As soon as btrfs reports that a file system is ready, systemd will pick it up. This is handled with the btrfs udev built-in, and invoked via /usr/lib/udev/rules.d/64-btrfs.rules. rootflags has no influence on that, as at that point it is not clear whether the block device will be the once that carries the root file system, or any other file system. Not sure what we should be doing about this. Maybe introduce a new btrfs=degraded switch that acts globally, and influences the udev built-in? Kay? So, as it turns out there's no kernel APi available to check whether a btrfs raid array is now complete enough for degraded mode to succeed. There's only a way to check whether it is fully complete. And even if we had an API for this, how would this even work at all? I mean, just having a catchall switch to boot in degraded mode is really dangerous if people have more than one array and we might end up mounting an fs in degraded mode that actually is fully available if we just waited 50ms longer... I mean this is even the problem with just one array: if you have redundancy of 3 disks, when do you start mounting the thing when degraded mode is requested on the kernel command line? as soon as degrdaded mounting is possible (thus fucking up possible all 3 disks that happened to show up last), or later? I have no idea how this all should work really, it's a giant mess. There probably needs to be some btrfs userspace daemon thing that watches btrfs arrays and does some magic if they timeout. But for now I am pretty sure we should just leave everything in fully manual mode, that's the safest thing to do... 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] timed out waiting for device dev-disk-by\x2duuid
On 05/15/2014 08:16 PM, Lennart Poettering wrote: On Thu, 15.05.14 19:29, Lennart Poettering (lenn...@poettering.net) wrote: On Mon, 12.05.14 20:48, Chris Murphy (li...@colorremedies.com) wrote: [...] So, as it turns out there's no kernel APi available to check whether a btrfs raid array is now complete enough for degraded mode to succeed. There's only a way to check whether it is fully complete. And even if we had an API for this, how would this even work at all? In what this should be different than the normal RAID system ? In both case there are two timeout: the first one is for waiting the full system, the second one is for the minimal set of disks to a degraded mode. If even the second timeout is passed, then we should consider the filesystem not build-able. How it is handle for the RAID system ? Knowing that we should consider to apply the same strategies fro btrfs (may be we need some userspace tool to do that) mean, just having a catchall switch to boot in degraded mode is really dangerous if people have more than one array and we might end up mounting an fs in degraded mode that actually is fully available if we just waited 50ms longer... I mean this is even the problem with just one array: if you have redundancy of 3 disks, when do you start mounting the thing when degraded mode is requested on the kernel command line? as soon as degrdaded mounting is possible (thus fucking up possible all 3 disks that happened to show up last), or later? I have no idea how this all should work really, it's a giant mess. There probably needs to be some btrfs userspace daemon thing that watches btrfs arrays and does some magic if they timeout. But for now I am pretty sure we should just leave everything in fully manual mode, that's the safest thing to do... Lennart -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it 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
Re: [systemd-devel] timed out waiting for device dev-disk-by\x2duuid
On May 15, 2014, at 12:16 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 15.05.14 19:29, Lennart Poettering (lenn...@poettering.net) wrote: On Mon, 12.05.14 20:48, Chris Murphy (li...@colorremedies.com) wrote: Two device Btrfs volume, with one device missing (simulated) will not boot, even with rootflags=degraded set which is currently required to enable Btrfs degraded mounts. Upon reaching a dracut shell after basic.target fails with time out, I can mount -o subvol=root,degraded and exit and continue boot normally with just the single device. The problem seems to be that systemd (udev?) is not finding the volume by uuid for some reason, and therefore not attempting to mount it. But I don't know why it can't find it, or even how the find by uuid mechanism works this early in boot. So I'm not sure if this is a systemd or udev bug, or a dracut, or kernel bug. The problem happens with systemd 208-9.fc20 with kernel 3.11.10-301.fc20, and systemd 212-4.fc21 and kernel 3.15.0-0.rc5.git0.1.fc21. As soon as btrfs reports that a file system is ready, systemd will pick it up. This is handled with the btrfs udev built-in, and invoked via /usr/lib/udev/rules.d/64-btrfs.rules. rootflags has no influence on that, as at that point it is not clear whether the block device will be the once that carries the root file system, or any other file system. Not sure what we should be doing about this. Maybe introduce a new btrfs=degraded switch that acts globally, and influences the udev built-in? Kay? So, as it turns out there's no kernel APi available to check whether a btrfs raid array is now complete enough for degraded mode to succeed. There's only a way to check whether it is fully complete. And even if we had an API for this, how would this even work at all? I mean, just having a catchall switch to boot in degraded mode is really dangerous if people have more than one array and we might end up mounting an fs in degraded mode that actually is fully available if we just waited 50ms longer... I mean this is even the problem with just one array: if you have redundancy of 3 disks, when do you start mounting the thing when degraded mode is requested on the kernel command line? as soon as degrdaded mounting is possible (thus fucking up possible all 3 disks that happened to show up last), or later? I have no idea how this all should work really, it's a giant mess. There probably needs to be some btrfs userspace daemon thing that watches btrfs arrays and does some magic if they timeout. But for now I am pretty sure we should just leave everything in fully manual mode, that's the safest thing to do… Is it that the existing udev rule either doesn't know, or doesn't have a way of knowing, that rootflags=degraded should enable only the root=UUID device to bypass the ready rule? Does udev expect a different readiness state to attempt a mount, than a manual mount from dracut shell? I'm confused why the Btrfs volume is not ready for systemd which then doesn't even attempt to mount it; and yet at a dracut shell it is ready when I do the mount manually. That seems like two readiness states. I'd say it's not udev's responsibility, but rather Btrfs kernel code, to make sure things don't get worse with the file system, regardless of what devices it's presented with. At the time it tries to do the mount, it has its own logic for normal and degraded mounts whether the minimum number of devices are present or not and if not it fails. The degraded mount is also per volume, not global. For example if I remove a device, and boot degraded and work for a few hours making lots of changes (even doing a system update, which is probably insane to do), I can later reboot with the stale device attached and Btrfs figures it out, passively. That means it figures out if there's a newer copy when a file is read, and forwards the newest copy to user space, and fixes the stale copy on the previously missing device. A manual balance ensures all new files also have redundancy. I think it's intended eventually to have a smarter balance catch up filter that can also run automatically in such a case. In any case the file system isn't trashed. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] timed out waiting for device dev-disk-by\x2duuid
On Thu, May 15, 2014 at 10:57 PM, Goffredo Baroncelli kreij...@libero.it wrote: On 05/15/2014 08:16 PM, Lennart Poettering wrote: On Thu, 15.05.14 19:29, Lennart Poettering (lenn...@poettering.net) wrote: On Mon, 12.05.14 20:48, Chris Murphy (li...@colorremedies.com) wrote: [...] So, as it turns out there's no kernel APi available to check whether a btrfs raid array is now complete enough for degraded mode to succeed. There's only a way to check whether it is fully complete. And even if we had an API for this, how would this even work at all? In what this should be different than the normal RAID system ? In both case there are two timeout: the first one is for waiting the full system, the second one is for the minimal set of disks to a degraded mode. If even the second timeout is passed, then we should consider the filesystem not build-able. How it is handle for the RAID system ? Knowing that we should consider to apply the same strategies fro btrfs (may be we need some userspace tool to do that) RAID is not handled by systemd, it is handled by other tools or not at all. Initrds have some logic here, but nothing convincing, and it is just the same mess as this. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 15/05/14 18:27, Lennart Poettering wrote: Well, something appears to create your device nodes, and it shouldn't do that... On a udev system userspace never creates any device nodes, that's done on its own by the kernel via devtmpfs, udev then just creates symlinks on top, or changes access rights. It appears that your LVM/DM installation for some reason created device nodes anyway, and you need to figure out why it did that, and turn this off. It might be in your initrd... Hah, progress: I think I pinpointed the culprit. libdm checks whether udev is running and falls back to non-udev code otherwise. When the boot fails, this is what I get: | May 15 22:06:46 pinky systemd-udevd[1361]: starting version 212 | May 15 22:06:46 pinky systemd[1]: Starting udev Kernel Socket. | May 15 22:06:46 pinky systemd[1]: Listening on udev Kernel Socket. | May 15 22:06:46 pinky systemd[1]: Starting udev Control Socket. | May 15 22:06:46 pinky systemd[1]: Listening on udev Control Socket. | May 15 22:06:46 pinky systemd[1]: Starting udev Coldplug all Devices... | May 15 22:06:46 pinky systemd[1]: Starting system-systemd\x2dcryptsetup.slice. | May 15 22:06:46 pinky systemd[1]: Created slice system-systemd\x2dcryptsetup.slice. | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for swap... | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for videos... | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for data... | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for home... | May 15 22:06:46 pinky systemd[1]: Started udev Coldplug all Devices. | May 15 22:06:46 pinky systemd[1]: Starting udev Wait for Complete Device Initialization... | May 15 22:06:46 pinky systemd-cryptsetup[2436]: Set cipher twofish, mode xts-essiv:wp256, key size 512 bits for device /dev/disk/by-uuid/57d30bae-878a-4931-bc39-10cc18b92486. | May 15 22:06:46 pinky systemd-cryptsetup[2434]: Set cipher twofish, mode xts-essiv:wp256, key size 512 bits for device /dev/disk/by-uuid/ee5e92a6-18b6-4247-a1d8-8379b01928fb. | May 15 22:06:46 pinky systemd-cryptsetup[2433]: Set cipher twofish, mode xts-essiv:wp256, key size 512 bits for device /dev/disk/by-uuid/b1c029d2-515b-47a1-becf-59c1f5191e43. | May 15 22:06:46 pinky systemd-cryptsetup[2435]: Set cipher twofish, mode xts-essiv:rmd256, key size 512 bits for device /dev/disk/by-uuid/72c01d1e-ac93-4263-93d7-fb293dfe49c0. | May 15 22:06:46 pinky systemd[1]: Started Create Static Device Nodes in /dev. | May 15 22:06:46 pinky systemd[1]: Starting udev Kernel Device Manager... | May 15 22:06:46 pinky systemd-udevd[2485]: starting version 212 | May 15 22:06:47 pinky systemd[1]: Mounted Runtime Directory. | May 15 22:06:47 pinky systemd[1]: Mounted Lock Directory. | May 15 22:06:47 pinky systemd[1]: Started udev Kernel Device Manager. | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG udev: open_queue_file failed with errno 2 | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG libdm:_check_udev_is_running: Udev is not running. Not using udev synchronisation code. So the udev queue file does not yet exist, libdm thinks the system is not running udev and things go wrong... I also was lucky enough to get one of the rare good boots right after I put in my debug prints (I was fearing a Heisenbug here for a minute) So here it is for comparison: | May 15 22:02:10 pinky systemd-udevd[1362]: starting version 212 | May 15 22:02:10 pinky systemd[1]: Starting udev Kernel Socket. | May 15 22:02:10 pinky systemd[1]: Listening on udev Kernel Socket. | May 15 22:02:10 pinky systemd[1]: Starting udev Control Socket. | May 15 22:02:10 pinky systemd[1]: Listening on udev Control Socket. | May 15 22:02:10 pinky systemd[1]: Starting udev Coldplug all Devices... | May 15 22:02:10 pinky systemd[1]: Starting system-systemd\x2dcryptsetup.slice. | May 15 22:02:10 pinky systemd[1]: Created slice system-systemd\x2dcryptsetup.slice. | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for swap... | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for videos... | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for data... | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for home... | May 15 22:02:10 pinky systemd[1]: Starting File System Check on Root Device... | May 15 22:02:10 pinky systemd-udevd[2464]: starting version 212 | May 15 22:02:10 pinky systemd[1]: Starting Create Static Device Nodes in /dev... | May 15 22:02:10 pinky systemd[1]: Started udev Coldplug all Devices. | May 15 22:02:10 pinky systemd[1]: Starting udev Wait for Complete Device Initialization... | May 15 22:02:10 pinky systemd[1]: Mounted Runtime Directory. | May 15 22:02:10 pinky systemd[1]: Mounted Lock Directory. | May 15 22:02:10 pinky systemd-cryptsetup[2437]: Set cipher twofish, mode xts-essiv:wp256, key size 512 bits for device
Re: [systemd-devel] timed out waiting for device dev-disk-by\x2duuid
On Thu, May 15, 2014 at 10:57 PM, Chris Murphy li...@colorremedies.com wrote: On May 15, 2014, at 12:16 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 15.05.14 19:29, Lennart Poettering (lenn...@poettering.net) wrote: On Mon, 12.05.14 20:48, Chris Murphy (li...@colorremedies.com) wrote: Two device Btrfs volume, with one device missing (simulated) will not boot, even with rootflags=degraded set which is currently required to enable Btrfs degraded mounts. Upon reaching a dracut shell after basic.target fails with time out, I can mount -o subvol=root,degraded and exit and continue boot normally with just the single device. The problem seems to be that systemd (udev?) is not finding the volume by uuid for some reason, and therefore not attempting to mount it. But I don't know why it can't find it, or even how the find by uuid mechanism works this early in boot. So I'm not sure if this is a systemd or udev bug, or a dracut, or kernel bug. The problem happens with systemd 208-9.fc20 with kernel 3.11.10-301.fc20, and systemd 212-4.fc21 and kernel 3.15.0-0.rc5.git0.1.fc21. As soon as btrfs reports that a file system is ready, systemd will pick it up. This is handled with the btrfs udev built-in, and invoked via /usr/lib/udev/rules.d/64-btrfs.rules. rootflags has no influence on that, as at that point it is not clear whether the block device will be the once that carries the root file system, or any other file system. Not sure what we should be doing about this. Maybe introduce a new btrfs=degraded switch that acts globally, and influences the udev built-in? Kay? So, as it turns out there's no kernel APi available to check whether a btrfs raid array is now complete enough for degraded mode to succeed. There's only a way to check whether it is fully complete. And even if we had an API for this, how would this even work at all? I mean, just having a catchall switch to boot in degraded mode is really dangerous if people have more than one array and we might end up mounting an fs in degraded mode that actually is fully available if we just waited 50ms longer... I mean this is even the problem with just one array: if you have redundancy of 3 disks, when do you start mounting the thing when degraded mode is requested on the kernel command line? as soon as degrdaded mounting is possible (thus fucking up possible all 3 disks that happened to show up last), or later? I have no idea how this all should work really, it's a giant mess. There probably needs to be some btrfs userspace daemon thing that watches btrfs arrays and does some magic if they timeout. But for now I am pretty sure we should just leave everything in fully manual mode, that's the safest thing to do… Is it that the existing udev rule either doesn't know, or doesn't have a way of knowing, that rootflags=degraded should enable only the root=UUID device to bypass the ready rule? Does udev expect a different readiness state to attempt a mount, than a manual mount from dracut shell? I'm confused why the Btrfs volume is not ready for systemd which then doesn't even attempt to mount it; and yet at a dracut shell it is ready when I do the mount manually. That seems like two readiness states. The btrfs kernel state has only one state, and that is what udev reacts to. I'd say it's not udev's responsibility, but rather Btrfs kernel code, to make sure things don't get worse with the file system, regardless of what devices it's presented with. At the time it tries to do the mount, it has its own logic for normal and degraded mounts whether the minimum number of devices are present or not and if not it fails. The degraded mount is also per volume, not global. For example if I remove a device, and boot degraded and work for a few hours making lots of changes (even doing a system update, which is probably insane to do), I can later reboot with the stale device attached and Btrfs figures it out, passively. That means it figures out if there's a newer copy when a file is read, and forwards the newest copy to user space, and fixes the stale copy on the previously missing device. A manual balance ensures all new files also have redundancy. I think it's intended eventually to have a smarter balance catch up filter that can also run automatically in such a case. In any case the file system isn't trashed. The problem is when to actively force to degrade things when devices do not show up in time. That is nothing the kernel can know, it would need to be userspace making that decision. But udev does not really have that information at that level, it would need to try until the kernel is satisfied mounting a volume degraded. This all is probably not a job for udev or systemd, but for a specialized storage daemon which has explicit configuration/policy in which way to mess around with the user's data. This is not an area where we should try to be smart; falling back
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On Thu, May 15, 2014 at 11:15 PM, Andy Kittner andy.kitt...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 15/05/14 18:27, Lennart Poettering wrote: Well, something appears to create your device nodes, and it shouldn't do that... On a udev system userspace never creates any device nodes, that's done on its own by the kernel via devtmpfs, udev then just creates symlinks on top, or changes access rights. It appears that your LVM/DM installation for some reason created device nodes anyway, and you need to figure out why it did that, and turn this off. It might be in your initrd... Hah, progress: I think I pinpointed the culprit. libdm checks whether udev is running and falls back to non-udev code otherwise. When the boot fails, this is what I get: | May 15 22:06:46 pinky systemd-udevd[1361]: starting version 212 | May 15 22:06:46 pinky systemd[1]: Starting udev Kernel Socket. | May 15 22:06:46 pinky systemd[1]: Listening on udev Kernel Socket. | May 15 22:06:46 pinky systemd[1]: Starting udev Control Socket. | May 15 22:06:46 pinky systemd[1]: Listening on udev Control Socket. | May 15 22:06:46 pinky systemd[1]: Starting udev Coldplug all Devices... | May 15 22:06:46 pinky systemd[1]: Starting system-systemd\x2dcryptsetup.slice. | May 15 22:06:46 pinky systemd[1]: Created slice system-systemd\x2dcryptsetup.slice. | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for swap... | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for videos... | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for data... | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for home... | May 15 22:06:46 pinky systemd[1]: Started udev Coldplug all Devices. | May 15 22:06:46 pinky systemd[1]: Starting udev Wait for Complete Device Initialization... | May 15 22:06:46 pinky systemd-cryptsetup[2436]: Set cipher twofish, mode xts-essiv:wp256, key size 512 bits for device /dev/disk/by-uuid/57d30bae-878a-4931-bc39-10cc18b92486. | May 15 22:06:46 pinky systemd-cryptsetup[2434]: Set cipher twofish, mode xts-essiv:wp256, key size 512 bits for device /dev/disk/by-uuid/ee5e92a6-18b6-4247-a1d8-8379b01928fb. | May 15 22:06:46 pinky systemd-cryptsetup[2433]: Set cipher twofish, mode xts-essiv:wp256, key size 512 bits for device /dev/disk/by-uuid/b1c029d2-515b-47a1-becf-59c1f5191e43. | May 15 22:06:46 pinky systemd-cryptsetup[2435]: Set cipher twofish, mode xts-essiv:rmd256, key size 512 bits for device /dev/disk/by-uuid/72c01d1e-ac93-4263-93d7-fb293dfe49c0. | May 15 22:06:46 pinky systemd[1]: Started Create Static Device Nodes in /dev. | May 15 22:06:46 pinky systemd[1]: Starting udev Kernel Device Manager... | May 15 22:06:46 pinky systemd-udevd[2485]: starting version 212 | May 15 22:06:47 pinky systemd[1]: Mounted Runtime Directory. | May 15 22:06:47 pinky systemd[1]: Mounted Lock Directory. | May 15 22:06:47 pinky systemd[1]: Started udev Kernel Device Manager. | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG udev: open_queue_file failed with errno 2 | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG libdm:_check_udev_is_running: Udev is not running. Not using udev synchronisation code. So the udev queue file does not yet exist, libdm thinks the system is not running udev and things go wrong... I also was lucky enough to get one of the rare good boots right after I put in my debug prints (I was fearing a Heisenbug here for a minute) So here it is for comparison: | May 15 22:02:10 pinky systemd-udevd[1362]: starting version 212 | May 15 22:02:10 pinky systemd[1]: Starting udev Kernel Socket. | May 15 22:02:10 pinky systemd[1]: Listening on udev Kernel Socket. | May 15 22:02:10 pinky systemd[1]: Starting udev Control Socket. | May 15 22:02:10 pinky systemd[1]: Listening on udev Control Socket. | May 15 22:02:10 pinky systemd[1]: Starting udev Coldplug all Devices... | May 15 22:02:10 pinky systemd[1]: Starting system-systemd\x2dcryptsetup.slice. | May 15 22:02:10 pinky systemd[1]: Created slice system-systemd\x2dcryptsetup.slice. | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for swap... | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for videos... | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for data... | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for home... | May 15 22:02:10 pinky systemd[1]: Starting File System Check on Root Device... | May 15 22:02:10 pinky systemd-udevd[2464]: starting version 212 | May 15 22:02:10 pinky systemd[1]: Starting Create Static Device Nodes in /dev... | May 15 22:02:10 pinky systemd[1]: Started udev Coldplug all Devices. | May 15 22:02:10 pinky systemd[1]: Starting udev Wait for Complete Device Initialization... | May 15 22:02:10 pinky systemd[1]: Mounted Runtime Directory. | May 15 22:02:10 pinky systemd[1]: Mounted Lock Directory. |
Re: [systemd-devel] [PATCH] timer: allow user to control activation time of cron-like timers
On Sun, 11.05.14 20:08, David Timothy Strauss (da...@davidstrauss.net) wrote: On Sun, May 11, 2014 at 9:30 AM, Alex B pkunk...@gmail.com wrote: It's ok for one timer, but not for the set of them. In general I'm want to schedule all maintenance tasks to 5 a.m. or lunch break and forget about them. This applies both for distro provided timers an my own. I'd personally like sort of timer that activates at times of low system load but with quality-of-service guarantees, like never running less frequently than once a day. I am very conservative with logic like this. Usually its better to just start the stuff and set it to SCHED_IDLE or so, simply because the kernel is better at scheduling than systemd could ever be at second-guessing when it might be a good time to start more... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/1] build-sys: build gummiboot executable only if HAVE_BLKID
On Wed, May 14, 2014 at 11:10 AM, Kang Hu hukangu...@gmail.com wrote: src/setup/setup.c depends on blkid library. so build gummiboot binary only if blkid library is available. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] test-kdbus: fixed unterminated string
On Mon, May 12, 2014 at 3:35 PM, Jacek Janczyk j.janc...@samsung.com wrote: Unterminated string array is used to populate random bus name in check_prepare_env(). Added proper termination. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timer: allow user to control activation time of cron-like timers
On Sun, 11.05.14 19:53, Alexander Bashmakov (pkunk...@gmail.com) wrote: I am not convinced that this is really desirable. daily is just a short way to write *-*-* 00:00:00. And if that is not desirable, then I'd just recommend writing *-*-* 05:00:00... I am not convinced we should allow redefining what daily resolves to... 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] timed out waiting for device dev-disk-by\x2duuid
On May 15, 2014, at 2:57 PM, Goffredo Baroncelli kreij...@libero.it wrote: On 05/15/2014 08:16 PM, Lennart Poettering wrote: On Thu, 15.05.14 19:29, Lennart Poettering (lenn...@poettering.net) wrote: On Mon, 12.05.14 20:48, Chris Murphy (li...@colorremedies.com) wrote: [...] So, as it turns out there's no kernel APi available to check whether a btrfs raid array is now complete enough for degraded mode to succeed. There's only a way to check whether it is fully complete. And even if we had an API for this, how would this even work at all? In what this should be different than the normal RAID system ? I think it's because with md, the array assembly is separate from fs mount. I don't know what timeout it uses, but it does do automatic degraded assembly eventually. Once assembled (degraded or normal) then the md device is ready and that's when udev rules start to apply and systemd will try to mount root fs. However on Btrfs, the degraded assembly and fs mount concepts are combined. So without degraded assembly first, it sounds like udev+systemd don't even try to mount the fs. At least that's my rudimentary understanding. The udev rule right now is asking if all Btrfs member devices are present and it sounds like that answer is no with a missing device; so a mount isn't even attempted by systemd rather than attempting a degraded mount specifically for the root=UUID device(s). What is parsing the boot parameters ro, root=, and rootflags=? Are those recognized by the kernel or systemd? In both case there are two timeout: the first one is for waiting the full system, the second one is for the minimal set of disks to a degraded mode. If even the second timeout is passed, then we should consider the filesystem not build-able. How it is handle for the RAID system ? Knowing that we should consider to apply the same strategies fro btrfs (may be we need some userspace tool to do that) Well that sounds like a user space tool to be in the initramfs so it can do this logic before systemd even attempt to mount rootfs. Or it's done by kernel code if it's possible for it to parse root=UUID and only care about the member devices for that volume. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] list-boots is incorrect, was: lost journal persistence
On Thu, 15.05.14 12:01, Chris Murphy (li...@colorremedies.com) wrote: On May 12, 2014, at 9:58 AM, Chris Murphy li...@colorremedies.com wrote: On May 12, 2014, at 7:06 AM, Kirill Elagin kirela...@gmail.com wrote: Could it be that all the boot ids are actually the same for some reason? I had this issue in a container when systemd was reading boot_id from `/proc/sys/kernel/random/boot_id` and since /proc was bind-mounted, boot_id always was host's boot_id. You can also run `journalctl -F _BOOT_ID` to see a set of all the boot ids recorded in the journal (this must agree with `journalctl --list-boots`. # journalctl --list-boots | wc -l 36 [root@rawhide ~]# journalctl -F _BOOT_ID | wc -l 80 # cat /proc/sys/kernel/random/boot_id 420fa190-e7dd-4cd7-b248-fd62417d7c02 # reboot ### # journalctl --list-boots | wc -l 36 [root@rawhide ~]# journalctl -F _BOOT_ID | wc -l 81 # cat /proc/sys/kernel/random/boot_id 1e0d5346-85cb-477b-9ae2-2cfb53097b97 So there are more boot ID's than there are list-boots, and list-boots doesn't increment while boot ID's do. And neither of these boot id's match any of the boot id's in --list-boots. Deleting the files in /var/log/journal/machineid/ fixes the problem on the Fedora 20 and Fedora Rawhide VMs experiencing this problem. If the files are restored, the problem returns. Yet --verify shows PASS for each log file. So it seems there's some kind of corruption or confusion with these log files. The btrfs filesystem is mounted with autodefrag option, for which there have been some problems with kernel 3.12 and older. But the Rawhide system has only been using 3.14 and 3.15 kernels so if there's still some problem I'm not sure how to isolate it since journalctl --verify seems to think the files are OK. Despite autodefrag enabled, the systemjournal has ~1450 fragments according to filefrag. If I boot from a rescue image so nothing is actively writing to these journal files, and recopy them such that they are each 1 extent only, then reboot the system, the list-boots changes. It actually goes down, from 45 boots to 31 boots, and stays stuck with additional reboots. Whereas BOOT_ID continues to increment as before. So just by copying the log files I get different --list-boot behavior. That's pretty strange. Yes, of course also btrfs check and scrub find no problems with either Fedora 20 or Fedora Rawhide Btrfs file systems this problem is happening on. This is certainly weird... Copying these files to ext4, does that change anything? I wonder if this might have to do something with time changes? Maybe the clock was not set correctly? Maybe it is a perms issue with some files not accessible to some users? 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] lost journal persistence
On Sat, 10.05.14 18:02, Chris Murphy (li...@colorremedies.com) wrote: So I thought maybe the flush is happening to /var before var subvolume is mounted there, but that's not the case; the reason why it's not empty is due to dhclient always creating one folder prior to var subvolume mounting at /var. /var/lib/dhclient Hmm, this looks like a bug. Is dhclient invoked before /var is mounted? If so, it really shouldn't be writing to /var... What component invokes dhclient this early? 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: --disable-networkd --enable-timesyncd should throw error
timesyncd requires networkd running. --- configure.ac | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configure.ac b/configure.ac index 16b689e..a19ca24 100644 --- a/configure.ac +++ b/configure.ac @@ -830,6 +830,8 @@ AC_ARG_ENABLE(timesyncd, AS_HELP_STRING([--disable-timesyncd], [disable timesync if test x$enable_timesyncd != xno; then have_timesyncd=yes fi +AS_IF([test x$have_timesyncd = xyes -a x$have_networkd != xyes], + [AC_MSG_ERROR([timesyncd requires networkd at runtime])]) AM_CONDITIONAL(ENABLE_TIMESYNCD, [test $have_timesyncd = yes]) AC_ARG_WITH(ntp-servers, -- 1.8.4.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd: create tun/tap device?
On Wed, 07.05.14 08:22, Christian Hesse (l...@eworm.de) wrote: Hello everybody, currently it is not possible to create tun/tap device with networkd. Is this feature planned? Anybody working on it? Sounds useful and reasonable. Added to TODO list. 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: --disable-networkd --enable-timesyncd should throw error
El 15/05/14 18:23, Cristian Rodríguez escribió: timesyncd requires networkd running. --- configure.ac | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configure.ac b/configure.ac index 16b689e..a19ca24 100644 --- a/configure.ac +++ b/configure.ac @@ -830,6 +830,8 @@ AC_ARG_ENABLE(timesyncd, AS_HELP_STRING([--disable-timesyncd], [disable timesync if test x$enable_timesyncd != xno; then have_timesyncd=yes fi +AS_IF([test x$have_timesyncd = xyes -a x$have_networkd != xyes], + [AC_MSG_ERROR([timesyncd requires networkd at runtime])]) AM_CONDITIONAL(ENABLE_TIMESYNCD, [test $have_timesyncd = yes]) AC_ARG_WITH(ntp-servers, This patch is incorrect, have_networkd is not yet set when the test runs and returns a false result. ignore it for now. -- Cristian I don't know the key to success, but the key to failure is trying to please everybody. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] Fix so install will work without 'ln --relative' support
On Wed, 07.05.14 08:54, Emil Sjölin (emil.sjo...@axis.com) wrote:
This fix makes sure that the package installation will work
on systems using versions of 'GNU coreutils' older than 8.16.
Please see tools/lnr.sh for limitations for this fix.
---
configure.ac | 16 ++
tools/lnr.sh | 93
++
2 files changed, 109 insertions(+)
create mode 100755 tools/lnr.sh
diff --git a/configure.ac b/configure.ac
index ead697b..399a52f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -315,6 +315,22 @@ fi
AM_CONDITIONAL(ENABLE_COVERAGE, [test $have_coverage = yes])
#
--
+ln_relative_support=yes
+AC_CHECK_PROG(ln_found, [ln], [yes], [no])
+if test x$ln_found = xno ; then
+AC_MSG_ERROR([*** ln support requested but the program was not
found])
+else
+ln_version_major=`ln --version | head -1 | cut -d ' ' -f 4 | cut -d
'.' -f 1`
+ln_version_minor=`ln --version | head -1 | cut -d ' ' -f 4 |
cut -d '.' -f 2`
Isn't head -n 1 more correct?
+if test $ln_version_major -lt 8 || test $ln_version_major -eq 8
-a $ln_version_minor -lt 16; then
+ln_relative_support=no
+fi
+if test x$ln_relative_support = xno; then
+LN_S=$(echo $LN_S | sed
s:ln:$srcdir\/tools\/lnr.sh:)
Shouldn't this be sed -e?
+fi
+fi
Hmm, if we ship this anyway, why not always use it? Otherwise it would
too easily bitrot...
THis would also allow removing much of the shell pipeline in the
configure script for this. I mean, these commands have changed all the
time in the past, for example sed quite a bit...
+
+#
--
have_kmod=no
AC_ARG_ENABLE(kmod, AS_HELP_STRING([--disable-kmod], [disable loadable
modules support]))
if test x$enable_kmod != xno; then
diff --git a/tools/lnr.sh b/tools/lnr.sh
new file mode 100755
index 000..74e1644
--- /dev/null
+++ b/tools/lnr.sh
@@ -0,0 +1,93 @@
No shebang?
+# This script makes the 'ln --relative' command work as expected on a system
where the
+# 'relative' option of 'ln' is not supported.
+#
+# NOTE:
+# The script assumes that the 'relative' option of 'ln' is used with any
+# of the following syntaxes:
+# '--relative'
+# '-r'
+#
+# The script will NOT handle combined options e.g. '-rf', '-ir' etc.
+# The script will also only handle the 1st form of the 'ln' command (see man
page
+# for the 'ln' command for the different forms).
+#
+
+
+while [ $# -gt 2 ]; do
+ string=$1
+ if [ ${string#-*} != $string ]; then
+ # argument is an option
+ if [ $string = $relop_1 ] || [ $string =
$relop_2 ]; then
Why not -o instead of ] || [?
I'd really prefer if somebody who's a true shell guru could look over
this. Harald? (Or Zbigniew?)
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: --disable-networkd --enable-timesyncd should throw error
On Thu, 15.05.14 18:23, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: timesyncd requires networkd running. It doesn't really Should work either way... --- configure.ac | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configure.ac b/configure.ac index 16b689e..a19ca24 100644 --- a/configure.ac +++ b/configure.ac @@ -830,6 +830,8 @@ AC_ARG_ENABLE(timesyncd, AS_HELP_STRING([--disable-timesyncd], [disable timesync if test x$enable_timesyncd != xno; then have_timesyncd=yes fi +AS_IF([test x$have_timesyncd = xyes -a x$have_networkd != xyes], + [AC_MSG_ERROR([timesyncd requires networkd at runtime])]) AM_CONDITIONAL(ENABLE_TIMESYNCD, [test $have_timesyncd = yes]) AC_ARG_WITH(ntp-servers, 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] timed out waiting for device dev-disk-by\x2duuid
On Thu, 15.05.14 15:54, Chris Murphy (li...@colorremedies.com) wrote: The udev rule right now is asking if all Btrfs member devices are present and it sounds like that answer is no with a missing device; so a mount isn't even attempted by systemd rather than attempting a degraded mount specifically for the root=UUID device(s). Yes, correct. And my suspicion is that if any more complex logic than this shall take place, then this should probably be managed by some kind of storage daemon still to be written, not udev. udev doesn't do timeouts, and has no clue about raid arrays. If things get this complex there really needs to be some other component in place that can handle this... What is parsing the boot parameters ro, root=, and rootflags=? Are those recognized by the kernel or systemd? When an initrd is used it is the initrd, otherwise the kernel itself. 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: --disable-networkd --enable-timesyncd should throw error
El 15/05/14 18:34, Lennart Poettering escribió:
On Thu, 15.05.14 18:23, Cristian Rodríguez
(crrodrig...@opensuse.org) wrote:
timesyncd requires networkd running.
It doesn't really Should work either way...
I tried that a few hours ago..
r = manager_network_monitor_listen(m);
if (r 0) {
log_error(Failed to listen to networkd events: %s,
strerror(-r));
goto out;
}
then it exits with failure.
--
Cristian
I don't know the key to success, but the key to failure is trying to
please everybody.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] list-boots is incorrect, was: lost journal persistence
On May 15, 2014, at 3:55 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 15.05.14 12:01, Chris Murphy (li...@colorremedies.com) wrote: On May 12, 2014, at 9:58 AM, Chris Murphy li...@colorremedies.com wrote: On May 12, 2014, at 7:06 AM, Kirill Elagin kirela...@gmail.com wrote: Could it be that all the boot ids are actually the same for some reason? I had this issue in a container when systemd was reading boot_id from `/proc/sys/kernel/random/boot_id` and since /proc was bind-mounted, boot_id always was host's boot_id. You can also run `journalctl -F _BOOT_ID` to see a set of all the boot ids recorded in the journal (this must agree with `journalctl --list-boots`. # journalctl --list-boots | wc -l 36 [root@rawhide ~]# journalctl -F _BOOT_ID | wc -l 80 # cat /proc/sys/kernel/random/boot_id 420fa190-e7dd-4cd7-b248-fd62417d7c02 # reboot ### # journalctl --list-boots | wc -l 36 [root@rawhide ~]# journalctl -F _BOOT_ID | wc -l 81 # cat /proc/sys/kernel/random/boot_id 1e0d5346-85cb-477b-9ae2-2cfb53097b97 So there are more boot ID's than there are list-boots, and list-boots doesn't increment while boot ID's do. And neither of these boot id's match any of the boot id's in --list-boots. Deleting the files in /var/log/journal/machineid/ fixes the problem on the Fedora 20 and Fedora Rawhide VMs experiencing this problem. If the files are restored, the problem returns. Yet --verify shows PASS for each log file. So it seems there's some kind of corruption or confusion with these log files. The btrfs filesystem is mounted with autodefrag option, for which there have been some problems with kernel 3.12 and older. But the Rawhide system has only been using 3.14 and 3.15 kernels so if there's still some problem I'm not sure how to isolate it since journalctl --verify seems to think the files are OK. Despite autodefrag enabled, the systemjournal has ~1450 fragments according to filefrag. If I boot from a rescue image so nothing is actively writing to these journal files, and recopy them such that they are each 1 extent only, then reboot the system, the list-boots changes. It actually goes down, from 45 boots to 31 boots, and stays stuck with additional reboots. Whereas BOOT_ID continues to increment as before. So just by copying the log files I get different --list-boot behavior. That's pretty strange. Yes, of course also btrfs check and scrub find no problems with either Fedora 20 or Fedora Rawhide Btrfs file systems this problem is happening on. This is certainly weird... Copying these files to ext4, does that change anything? Each time I copy, no matter the file system, I get a different number of list-boots results each time. Yet each time the source and destination sha256sums for the journal files are the same. It makes no sense. Same sha256sums yet different --list-boot behavior. It's a non-deterministic hell it seems. Once the journals are affected by whatever is happening, they're permanently weird. I think the state is sufficiently bizarre, with a huge pile of Btrfs patches applied in the 3.14 time frame (both systems ran 3.14 and 3.15 rc kernels) that this is just not worth looking at further. I'll keep the journals elsewhere, but I'm going to clear out /var/log/journal and let it start new ones from scratch and see how it goes, if the problem reoccurs. I wonder if this might have to do something with time changes? Maybe the clock was not set correctly? It's a VM on a laptop host. Time is always correct. Maybe it is a perms issue with some files not accessible to some users? They are all throw away test systems and I'm lazy so I only use root. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: --disable-networkd --enable-timesyncd should throw error
On Thu, 15.05.14 19:02, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
El 15/05/14 18:34, Lennart Poettering escribió:
On Thu, 15.05.14 18:23, Cristian Rodríguez
(crrodrig...@opensuse.org) wrote:
timesyncd requires networkd running.
It doesn't really Should work either way...
I tried that a few hours ago..
r = manager_network_monitor_listen(m);
if (r 0) {
log_error(Failed to listen to networkd events: %s,
strerror(-r));
goto out;
}
then it exits with failure.
What's the precise error?
Seems to work fine on my laptop that still has NetworkManager...
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] device: Add stub serialization methods to enable job serialization.
On Tue, 06.05.14 19:08, Michael Marineau (michael.marin...@coreos.com) wrote:
If a unit type doesn't provide its own serialization methods then
none of the generic serialization will happen either. For devices this
means jobs used for waiting on device dependencies are dropped during
reloads, breaking dependency state that was relying on those jobs.
Oh yuck! This is quite some bug, which I figure is the source of quite a
few bug reports we had where people were reloading the daemon during the
boot process...
I commited a different fix now which avoids installing stub callbacks,
and simply fixes to the core always serialize the job regardless if the
unit has anything else to serialize...
Please test!
---
src/core/device.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/src/core/device.c b/src/core/device.c
index 444286e..07c0860 100644
--- a/src/core/device.c
+++ b/src/core/device.c
@@ -130,6 +130,25 @@ static void device_dump(Unit *u, FILE *f, const char
*prefix) {
prefix, strna(d-sysfs));
}
+static int device_serialize(Unit *u, FILE *f, FDSet *fds) {
+assert(u);
+assert(f);
+assert(fds);
+
+return 0;
+}
+
+static int device_deserialize_item(Unit *u, const char *key, const char
*value, FDSet *fds) {
+assert(u);
+assert(key);
+assert(value);
+assert(fds);
+
+log_debug(Unknown serialization key '%s', key);
+
+return 0;
+}
+
_pure_ static UnitActiveState device_active_state(Unit *u) {
assert(u);
@@ -693,6 +712,9 @@ const UnitVTable device_vtable = {
.dump = device_dump,
+.serialize = device_serialize,
+.deserialize_item = device_deserialize_item,
+
.active_state = device_active_state,
.sub_state_to_string = device_sub_state_to_string,
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: --disable-networkd --enable-timesyncd should throw error
On Fri, May 16, 2014 at 1:20 AM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 15.05.14 19:02, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
El 15/05/14 18:34, Lennart Poettering escribió:
On Thu, 15.05.14 18:23, Cristian Rodríguez
(crrodrig...@opensuse.org) wrote:
timesyncd requires networkd running.
It doesn't really Should work either way...
I tried that a few hours ago..
r = manager_network_monitor_listen(m);
if (r 0) {
log_error(Failed to listen to networkd events: %s,
strerror(-r));
goto out;
}
then it exits with failure.
What's the precise error?
Seems to work fine on my laptop that still has NetworkManager...
But networkd runs on your machine and exports state.
We need to make timesyncd gracefully accepting that no networkd
around, or we should just make it depend on it.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd pam and O_CLOEXEC problem
On Mon, 05.05.14 20:33, dedede gfgfgf trtrtrtrtrtr (s.kabano...@mail.ru) wrote: Hello. During my testing of systemd pam sessions i discovered that session processes are not deleted automatically when i specify KillUserProcesses=yes in latest versions of systemd. Investigations showed that since in pam_systemd.so we started to dup() fifo descriptor problem appeared. Dup does not set O_CLOEXEC flag. So after fork/exec all child processes have that descriptor and when parent which open pam session dies, child processes continue to run. Thanks for the pointer! Fixed in git! 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] lost journal persistence
On May 15, 2014, at 3:58 PM, Lennart Poettering lenn...@poettering.net wrote: On Sat, 10.05.14 18:02, Chris Murphy (li...@colorremedies.com) wrote: So I thought maybe the flush is happening to /var before var subvolume is mounted there, but that's not the case; the reason why it's not empty is due to dhclient always creating one folder prior to var subvolume mounting at /var. /var/lib/dhclient Hmm, this looks like a bug. Is dhclient invoked before /var is mounted? Seems not to be, as the first reported instance of dhclient is afterward and /var already has something in it. Maybe NetworkManger creates it? [2.839950] f20v.localdomain systemd[1]: Mounting /var... [2.840310] f20v.localdomain systemd[1]: var.mount: Directory /var to mount over is not empty, mounting anyway. [2.840589] f20v.localdomain systemd[1]: Mounting /home... [2.848319] f20v.localdomain systemd[1]: Mounting /boot... [2.848386] f20v.localdomain kernel: BTRFS: device label f20 devid 1 transid 3961 /dev/sda2 [2.849926] f20v.localdomain kernel: BTRFS: device label f20 devid 1 transid 3961 /dev/sda2 [2.854250] f20v.localdomain kernel: BTRFS: device label f20 devid 1 transid 3961 /dev/sda2 [2.875834] f20v.localdomain systemd[1]: Mounted /home. [2.876293] f20v.localdomain systemd[1]: Mounted /var. [3.745285] f20v.localdomain NetworkManager[393]: info dhclient started with pid 477 If so, it really shouldn't be writing to /var... What component invokes dhclient this early? The time stamp of /var/lib is 17:03, which matches up with startup time, not prior shutdown time. So it looks created at startup time. Seems crude but I could figure out how to set an selinux label on the wrong /var to prevent anything from creating things there, and see what explodes? Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] GuessMainPID=no required to make daemon reload work
On Wed, 07.05.14 09:02, Colin Guthrie (gm...@colin.guthr.ie) wrote: 'Twas brillig, and Gerd v. Egidy at 05/05/14 22:17 did gyre and gimble: Secondly, the killing is asynchronous. When looking at http://www.freedesktop.org/software/systemd/man/systemd.service.html I see /bin/kill -HUP $MAINPID recommended. How is this different in regards to asynchronism than the command I used above? In both cases systemd doesn't know when the reload is finished and if it was successful or not. I'm not sure the man page recommends it as such, but it's certainly there as an example, so I take your point. It should probably be heavily caveated in the man page though as per Lennart's previous comments. Added a comment about this now to git. 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] GuessMainPID=no required to make daemon reload work
On Mon, 05.05.14 23:28, Gerd v. Egidy (li...@egidy.de) wrote: Generally, it's not a good idea to keep file locks for a longer period of time... YOu should really just take them while you write a file, and then release them, but not keep them forever... I keep the lock on the pidfile as long as the daemon is running. I think this is the best way to prevent a second daemon from running in parallel: If the first instance of your program just writes the pid into the pidfile and the second instance reads it and checks if this pid is alive, the first instance could have died ages ago and the pid was reused by another program. One option is to include the PID starttime in the file, as a protection against collisions. Note though that systemd actually removes the PID file when a daemon terminates, a systemd system is hence not vulnerable to this. But again, it's generally not a good idea to keep file locks for a longer period of time, much as with mutexes... You don't want to make other apps which try to get an atomic view on the file hang for long. Actually, note that anyone who can open a file can take a lock on it. If the PID file is readable by unpriviliged users taking a lock on the PID file from the daemon is also an effective way to DoS it hence. Hence, it's probably better to avoid all locking games altogther. Yes, UNIX sucks... Or if the whole system crashes and is rebooted, another program could have been issued the same pid as the daemon had before. So the new instance won't start. On systemd that's not possible either as /run can only be tmpfs and thus is flushed on reboot. 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: --disable-networkd --enable-timesyncd should throw error
El 15/05/14 19:20, Lennart Poettering escribió: ilure. What's the precise error? Failed to listen to networkd events: No such file or directory) -- Cristian I don't know the key to success, but the key to failure is trying to please everybody. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 15/05/14 23:38, Lennart Poettering wrote: On Thu, 15.05.14 23:15, Andy Kittner (andy.kitt...@gmail.com) wrote: | May 15 22:06:47 pinky systemd[1]: Mounted Runtime Directory. | May 15 22:06:47 pinky systemd[1]: Mounted Lock Directory. This looks like remains from a *really* old systemd version. THis does not exist anymore. What distribution is this? Gentoo This used to bind mount /run to /var/run, and similar for /var/lock. Yeah this appears to do something similar, but it's provided by sys-apps/gentoo-systemd-integration not systemd itself, so I guess it's something distro-specific. | May 15 22:06:47 pinky systemd[1]: Started udev Kernel Device Manager. | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG udev: open_queue_file failed with errno 2 | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG libdm:_check_udev_is_running: Udev is not running. Not using udev synchronisation code. So the udev queue file does not yet exist, libdm thinks the system is not running udev and things go wrong... This really should be turned off in libdm. It's really stupid and broken. We start these things in parallel, they create these races without reason. Since ages we don't support non-devtmpfs kernels anymore, [...] And that's fine for systemd, but it doesn't necessarily mean that other projects work under the same assumption. And IMHO especially for critical things like lvm it is a good thing to support minimal configurations. What does libdm even check there precisely? They call udev_queue_get_udev_is_active() from libudev to determine whether the system currently runs udev, or not. See check_udev_is_running(): https://git.fedorahosted.org/cgit/lvm2.git/tree/libdm/libdm-common.c#n2071 [...] Nope, we don't need more synchronization. The LVM guys should stop doing mknod() on their own. And if they insist, your distro should turn that off, or patch it out. That sounds like this can only end in a systemd vs. the rest of the world flamewar and I have no intention to get involved in one of those, so I guess I'll just work around it locally and call it a day, saves nerves and effort for everyone. Anyway, thanks for the pointer with the device node, to me that looked like a rather harmless warning and not like a serious issue. Regards, Andy -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTdWfcAAoJED4ymUd/KFGwP9MQALqupxFKdl42W/6g83uUI0uR zzNNpJhry2Iv/pR/foQhl3ml3Y9B0h+pECH0/ey44dXWPsEjwpHTInS62vDouibO 6c22a8SJFXhNJdyrzXbaFWkni9yrJqHZHQGfydza0sgH0bgZxozTs7Y3/ANShzrI l2qcRhYI3Ea3XFDvs+9BnjOiPpccqS1J2LXnBpTLgiZ44o/9dcMVlIXXli98zi81 ySUfnuP3SvtUJnbKicv/7Ei0DVSz8IoAdqP/5nAEZE32ZvPhPCyh1TRRBPxaQv67 EVF3lwIsNSKJ5ggxjCEWCsId4WXGkOxHDqS4EAZOVdYswREvnhqBWkQ8Y53A/KyM 4KPKUXh8Ovf5skbo4lZTNqWlnSOhjhwMD4z37vGQuy11QYRZQZvfDgEnHF4uWaBy ym7/zN+FOdGkmyx4VfDOlkjnFsLcBQ+J6loV0dRV6iAwB9Bx28FiNuwiQSdf4Fzd twfFTA4ANiKFMydHxA7usWzxLrNH+Qyr6W2tzW01DQVFnb/LPc9nwnnfoc48eViE ts5cjWqITMAF2mXX51vGoCp+yyXh56S0NrHqGQ2bvWi0mVtD9zkTrovBOdU2Mgt5 /WoFV6J658hS65A4fYBr8PmPNZ4dWBAbJZRjKVaXYqZusoXS194B8zHQZRKYq1Q5 YZggRD4teAxNPOKtzVqr =jBQS -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On 15/05/14 23:33, Kay Sievers wrote: On Thu, May 15, 2014 at 11:15 PM, Andy Kittner andy.kitt...@gmail.com wrote: What is Mounted Runtime Directory? Is that /run? That must be part of PID1's own early initialization, nothing to run externally. I thought so from the name, but aparently it is just some /var/run compatibility stuff (see my response to Lennart). Regards, Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timer: allow user to control activation time of cron-like timers
On Thu, May 15, 2014 at 11:51:13PM +0200, Lennart Poettering wrote:
On Sun, 11.05.14 19:53, Alexander Bashmakov (pkunk...@gmail.com) wrote:
I am not convinced that this is really desirable. daily is just a
short way to write *-*-* 00:00:00. And if that is not desirable, then
I'd just recommend writing *-*-* 05:00:00... I am not convinced we
should allow redefining what daily resolves to...
In principle you're right, but this seems to be something that people
ask for, with cron. And with the usual setup where scripts are stored
in /etc/cron.{daily,weekly,...} is was trivial to adjust the date globally,
by modyfing the crontab entry which runs those directories. When switching
to systemd units as they are defined currently this convenience is lost.
I think it is reasonable request. This feature is backwards compatible,
and requires user intervention to activate, so I'd say we can redefine
daily not to necessarilly mean midnight.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] GuessMainPID=no required to make daemon reload work
On Thu, May 15, 2014 at 6:40 PM, Lennart Poettering lenn...@poettering.netwrote: But again, it's generally not a good idea to keep file locks for a longer period of time, much as with mutexes... You don't want to make other apps which try to get an atomic view on the file hang for long. If they don't want to hang, they don't have to. There are nonblocking calls to check for a conflicting advisory fcntl() lock. The pidfile should be private from random software anyways, other than the daemon itself and perhaps whatever tools or init system are managing start/stop. Actually, note that anyone who can open a file can take a lock on it. If the PID file is readable by unpriviliged users taking a lock on the PID file from the daemon is also an effective way to DoS it hence. And this can be solved with file/dir permissions (but thanks for the pointer, I hadn't considered this angle before!). IMHO, the method of taking an fcntl() writelock on a private pidfile is one of the most reliable methods around for this stuff in the general case outside of systemd-land. AFAIK it's just about the only reliable way that doesn't have inherent races or accidentally kill (or be DoS'd by) unrelated processes in corner cases. You don't even have to read the contents of the pidfile (although it's polite to write them for humans to glance at), as fcntl() will give you the pid of the running daemon which currently holds the writelock. If the running daemon dies prematurely, or a system with a persistent rundir rebooted, the fcntl() lock will be gone. So there's never any confusion as to whether some other process reusing an old pid is an instance of the correct daemon or not. As for such a portable daemon working under systemd, that's pretty trivial as well. It can continue to do the fcntl() lock on its private pidfile, not declare that pidfile to systemd, and instead use sd_notify() to send a MAINPID message after it has acquired the exclusive fcntl() lock. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] device: Add stub serialization methods to enable job serialization.
On Thu, May 15, 2014 at 4:24 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Tue, 06.05.14 19:08, Michael Marineau (michael.marin...@coreos.com) wrote:
If a unit type doesn't provide its own serialization methods then
none of the generic serialization will happen either. For devices this
means jobs used for waiting on device dependencies are dropped during
reloads, breaking dependency state that was relying on those jobs.
Oh yuck! This is quite some bug, which I figure is the source of quite a
few bug reports we had where people were reloading the daemon during the
boot process...
I commited a different fix now which avoids installing stub callbacks,
and simply fixes to the core always serialize the job regardless if the
unit has anything else to serialize...
Please test!
Looks good to me, thanks!
---
src/core/device.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/src/core/device.c b/src/core/device.c
index 444286e..07c0860 100644
--- a/src/core/device.c
+++ b/src/core/device.c
@@ -130,6 +130,25 @@ static void device_dump(Unit *u, FILE *f, const char
*prefix) {
prefix, strna(d-sysfs));
}
+static int device_serialize(Unit *u, FILE *f, FDSet *fds) {
+assert(u);
+assert(f);
+assert(fds);
+
+return 0;
+}
+
+static int device_deserialize_item(Unit *u, const char *key, const char
*value, FDSet *fds) {
+assert(u);
+assert(key);
+assert(value);
+assert(fds);
+
+log_debug(Unknown serialization key '%s', key);
+
+return 0;
+}
+
_pure_ static UnitActiveState device_active_state(Unit *u) {
assert(u);
@@ -693,6 +712,9 @@ const UnitVTable device_vtable = {
.dump = device_dump,
+.serialize = device_serialize,
+.deserialize_item = device_deserialize_item,
+
.active_state = device_active_state,
.sub_state_to_string = device_sub_state_to_string,
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] list-boots is incorrect, was: lost journal persistence
On Thu, May 15, 2014 at 05:19:28PM -0600, Chris Murphy wrote: On May 15, 2014, at 3:55 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 15.05.14 12:01, Chris Murphy (li...@colorremedies.com) wrote: On May 12, 2014, at 9:58 AM, Chris Murphy li...@colorremedies.com wrote: On May 12, 2014, at 7:06 AM, Kirill Elagin kirela...@gmail.com wrote: Could it be that all the boot ids are actually the same for some reason? I had this issue in a container when systemd was reading boot_id from `/proc/sys/kernel/random/boot_id` and since /proc was bind-mounted, boot_id always was host's boot_id. You can also run `journalctl -F _BOOT_ID` to see a set of all the boot ids recorded in the journal (this must agree with `journalctl --list-boots`. # journalctl --list-boots | wc -l 36 [root@rawhide ~]# journalctl -F _BOOT_ID | wc -l 80 # cat /proc/sys/kernel/random/boot_id 420fa190-e7dd-4cd7-b248-fd62417d7c02 # reboot ### # journalctl --list-boots | wc -l 36 [root@rawhide ~]# journalctl -F _BOOT_ID | wc -l 81 # cat /proc/sys/kernel/random/boot_id 1e0d5346-85cb-477b-9ae2-2cfb53097b97 So there are more boot ID's than there are list-boots, and list-boots doesn't increment while boot ID's do. And neither of these boot id's match any of the boot id's in --list-boots. Deleting the files in /var/log/journal/machineid/ fixes the problem on the Fedora 20 and Fedora Rawhide VMs experiencing this problem. If the files are restored, the problem returns. Yet --verify shows PASS for each log file. So it seems there's some kind of corruption or confusion with these log files. The btrfs filesystem is mounted with autodefrag option, for which there have been some problems with kernel 3.12 and older. But the Rawhide system has only been using 3.14 and 3.15 kernels so if there's still some problem I'm not sure how to isolate it since journalctl --verify seems to think the files are OK. Despite autodefrag enabled, the systemjournal has ~1450 fragments according to filefrag. If I boot from a rescue image so nothing is actively writing to these journal files, and recopy them such that they are each 1 extent only, then reboot the system, the list-boots changes. It actually goes down, from 45 boots to 31 boots, and stays stuck with additional reboots. Whereas BOOT_ID continues to increment as before. So just by copying the log files I get different --list-boot behavior. That's pretty strange. Yes, of course also btrfs check and scrub find no problems with either Fedora 20 or Fedora Rawhide Btrfs file systems this problem is happening on. This is certainly weird... Copying these files to ext4, does that change anything? Each time I copy, no matter the file system, I get a different number of list-boots results each time. Yet each time the source and destination sha256sums for the journal files are the same. It makes no sense. Same sha256sums yet different --list-boot behavior. It's a non-deterministic hell it seems. Once the journals are affected by whatever is happening, they're permanently weird. Probably the order of files in the directory (ls -U) changes randomly upon copying to a different fs. I think the state is sufficiently bizarre, with a huge pile of Btrfs patches applied in the 3.14 time frame (both systems ran 3.14 and 3.15 rc kernels) that this is just not worth looking at further. I'll keep the journals elsewhere, but I'm going to clear out /var/log/journal and let it start new ones from scratch and see how it goes, if the problem reoccurs. I wouldn't rule out an issue with the journal code... Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] Fix so install will work without 'ln --relative' support
On Fri, May 16, 2014 at 12:30:45AM +0200, Lennart Poettering wrote:
On Wed, 07.05.14 08:54, Emil Sjölin (emil.sjo...@axis.com) wrote:
This fix makes sure that the package installation will work
on systems using versions of 'GNU coreutils' older than 8.16.
Please see tools/lnr.sh for limitations for this fix.
---
configure.ac | 16 ++
tools/lnr.sh | 93
++
2 files changed, 109 insertions(+)
create mode 100755 tools/lnr.sh
diff --git a/configure.ac b/configure.ac
index ead697b..399a52f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -315,6 +315,22 @@ fi
AM_CONDITIONAL(ENABLE_COVERAGE, [test $have_coverage = yes])
#
--
+ln_relative_support=yes
+AC_CHECK_PROG(ln_found, [ln], [yes], [no])
+if test x$ln_found = xno ; then
+AC_MSG_ERROR([*** ln support requested but the program was not
found])
This error message is wrong: there was no request. It should be something
like ln is required.
+else
+ln_version_major=`ln --version | head -1 | cut -d ' ' -f 4 | cut
-d '.' -f 1`
+ln_version_minor=`ln --version | head -1 | cut -d ' ' -f 4 |
cut -d '.' -f 2`
Isn't head -n 1 more correct?
+if test $ln_version_major -lt 8 || test $ln_version_major -eq
8 -a $ln_version_minor -lt 16; then
+ln_relative_support=no
+fi
+if test x$ln_relative_support = xno; then
+LN_S=$(echo $LN_S | sed
s:ln:$srcdir\/tools\/lnr.sh:)
The quoting here is ... complicated. If you count the quotes, what is
effectively
quoted are strings ln, \/tools\/lnr.sh. They don't contain shell special
characters,
so there's no need to quote them. OTOH, the parts which are _not_ quoted, might.
And why are slashes escaped?
LN_S=$(echo $LN_S | sed -E s|^[^ ]+|${srcdir}/tools/lnr.sh|)
This form has the advantage that it'll work if $LN_S e.g. has /bin/ln not ln,
and also if ${srcdir} contains spaces.
Shouldn't this be sed -e?
It's fine here, because no file is given.
+fi
+fi
Hmm, if we ship this anyway, why not always use it? Otherwise it would
too easily bitrot...
THis would also allow removing much of the shell pipeline in the
configure script for this. I mean, these commands have changed all the
time in the past, for example sed quite a bit...
Yeah, probably it's better to use it unconditionally. This will rid us of
the ugly version checks.
+#
--
have_kmod=no
AC_ARG_ENABLE(kmod, AS_HELP_STRING([--disable-kmod], [disable loadable
modules support]))
if test x$enable_kmod != xno; then
diff --git a/tools/lnr.sh b/tools/lnr.sh
new file mode 100755
index 000..74e1644
--- /dev/null
+++ b/tools/lnr.sh
@@ -0,0 +1,93 @@
No shebang?
+# This script makes the 'ln --relative' command work as expected on a
system where the
+# 'relative' option of 'ln' is not supported.
+#
+# NOTE:
+# The script assumes that the 'relative' option of 'ln' is used with any
+# of the following syntaxes:
+# '--relative'
+# '-r'
+#
+# The script will NOT handle combined options e.g. '-rf', '-ir' etc.
+# The script will also only handle the 1st form of the 'ln' command (see
man page
+# for the 'ln' command for the different forms).
+#
+
+
+while [ $# -gt 2 ]; do
+ string=$1
+ if [ ${string#-*} != $string ]; then
+ # argument is an option
+ if [ $string = $relop_1 ] || [ $string =
$relop_2 ]; then
Why not -o instead of ] || [?
I'd really prefer if somebody who's a true shell guru could look over
this. Harald? (Or Zbigniew?)
If I review it, do I get to become a true shell guru? ;)
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
