Re: [systemd-devel] [RFC PATCH] Fix so install will work without 'ln --relative' support

[Zbigniew Jędrzejewski-Szmek]

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

Re: [systemd-devel] list-boots is incorrect, was: lost journal persistence

[Zbigniew Jędrzejewski-Szmek]

On Thu, May 15, 2014 at 05:19:28PM -0600, Chris Murphy wrote:
> 
> On May 15, 2014, at 3:55 PM, Lennart Poettering  
> wrote:
> 
> > On Thu, 15.05.14 12:01, Chris Murphy (li...@colorremedies.com) wrote:
> > 
> >> 
> >> 
> >> On May 12, 2014, at 9:58 AM, Chris Murphy  wrote:
> >> 
> >>> 
> >>> On May 12, 2014, at 7:06 AM, Kirill Elagin  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// 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] [PATCH] device: Add stub serialization methods to enable job serialization.

[Michael Marineau]

On Thu, May 15, 2014 at 4:24 PM, Lennart Poettering
 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] GuessMainPID=no required to make daemon reload work

[Brandon Black]

On Thu, May 15, 2014 at 6:40 PM, Lennart Poettering
wrote:
>
> 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] timer: allow user to control activation time of cron-like timers

[Zbigniew Jędrzejewski-Szmek]

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] cryptsetup vs. swapon/fsck (some kind of race condition)

[Andy Kittner]

On 15/05/14 23:33, Kay Sievers wrote:
> On Thu, May 15, 2014 at 11:15 PM, Andy Kittner  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] cryptsetup vs. swapon/fsck (some kind of race condition)

[Andy Kittner]

-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] [PATCH] build: --disable-networkd --enable-timesyncd should throw error

[Cristian Rodríguez]

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] GuessMainPID=no required to make daemon reload work

[Lennart Poettering]

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] GuessMainPID=no required to make daemon reload work

[Lennart Poettering]

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] lost journal persistence

[Chris Murphy]

On May 15, 2014, at 3:58 PM, Lennart Poettering  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]:  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] systemd pam and O_CLOEXEC problem

[Lennart Poettering]

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] [PATCH] build: --disable-networkd --enable-timesyncd should throw error

[Kay Sievers]

On Fri, May 16, 2014 at 1:20 AM, Lennart Poettering
 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] [PATCH] device: Add stub serialization methods to enable job serialization.

[Lennart Poettering]

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

[Lennart Poettering]

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] list-boots is incorrect, was: lost journal persistence

[Chris Murphy]

On May 15, 2014, at 3:55 PM, Lennart Poettering  wrote:

> On Thu, 15.05.14 12:01, Chris Murphy (li...@colorremedies.com) wrote:
> 
>> 
>> 
>> On May 12, 2014, at 9:58 AM, Chris Murphy  wrote:
>> 
>>> 
>>> On May 12, 2014, at 7:06 AM, Kirill Elagin  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// 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

[Cristian Rodríguez]

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] timed out waiting for device dev-disk-by\x2duuid

[Lennart Poettering]

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

[Lennart Poettering]

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] [RFC PATCH] Fix so install will work without 'ln --relative' support

[Lennart Poettering]

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

[Cristian Rodríguez]

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] networkd: create tun/tap device?

[Lennart Poettering]

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

[systemd-devel] [PATCH] build: --disable-networkd --enable-timesyncd should throw error

[Cristian Rodríguez]

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] lost journal persistence

[Lennart Poettering]

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

Re: [systemd-devel] list-boots is incorrect, was: lost journal persistence

[Lennart Poettering]

On Thu, 15.05.14 12:01, Chris Murphy (li...@colorremedies.com) wrote:

> 
> 
> On May 12, 2014, at 9:58 AM, Chris Murphy  wrote:
> 
> > 
> > On May 12, 2014, at 7:06 AM, Kirill Elagin  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// 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] timed out waiting for device dev-disk-by\x2duuid

[Chris Murphy]

On May 15, 2014, at 2:57 PM, Goffredo Baroncelli  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] [PATCH] timer: allow user to control activation time of cron-like timers

[Lennart Poettering]

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] [PATCH] test-kdbus: fixed unterminated string

[Kay Sievers]

On Mon, May 12, 2014 at 3:35 PM, Jacek Janczyk  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 1/1] build-sys: build gummiboot executable only if HAVE_BLKID

[Kay Sievers]

On Wed, May 14, 2014 at 11:10 AM, Kang Hu  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] timer: allow user to control activation time of cron-like timers

[Lennart Poettering]

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  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] cryptsetup vs. swapon/fsck (some kind of race condition)

[Lennart Poettering]

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?

This used to bind mount /run to /var/run, and similar for /var/lock.

> | 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, so it's *always* wrong to invoke mknod(), since the kernel will
create the device nodes. Unless you run an early 2.6 kernels this is
completely wrong. I'd recommend filing a bug against the distribution to
remove this old crap from libdm. 

What does libdm even check there precisely?

> The main difference I spot is a longer interval between starting udev
> and the udev_is_running() check.
> Also, I guess "Mounted Runtime Directory" refers to /run, where the file
> in question resides? In the "bad" case this happens in the same second
> as the cryptsetup call...

/run is since a long time mounted from within PID 1 very early on, as
part of its initial setup, before running any unit or forking off any
other process.

> Anyway, my conclusion from this is that either the LVM guys need to
> use another method to detect that udev is running, or systemd should
> not start the cryptsetup stuff until udev is fully initialized.

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.

> Should I open a bug for LVM or for systemd?

Certainly not 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] cryptsetup vs. swapon/fsck (some kind of race condition)

[Kay Sievers]

On Thu, May 15, 2014 at 11:15 PM, Andy Kittner  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 Runti

Re: [systemd-devel] timed out waiting for device dev-disk-by\x2duuid

[Kay Sievers]

On Thu, May 15, 2014 at 10:57 PM, Chris Murphy  wrote:
> On May 15, 2014, at 12: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:
>>>
 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 expl

Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)

[Andy Kittner]

-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 
/dev/disk/by-uuid/ee5e92a6-18b

Re: [systemd-devel] timed out waiting for device dev-disk-by\x2duuid

[Kay Sievers]

On Thu, May 15, 2014 at 10:57 PM, Goffredo Baroncelli
 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] timed out waiting for device dev-disk-by\x2duuid

[Chris Murphy]

On May 15, 2014, at 12: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:
>> 
>>> 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

[Goffredo Baroncelli]

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

[Lennart Poettering]

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] list-boots is incorrect, was: lost journal persistence

[Chris Murphy]

On May 12, 2014, at 9:58 AM, Chris Murphy  wrote:

> 
> On May 12, 2014, at 7:06 AM, Kirill Elagin  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// 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] [PATCH] RFC/fsck: Allow to specify the fsck repair option in the cmdline

[Holger Freyther]

Lennart Poettering  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] [PATCH] timer: allow user to control activation time of cron-like timers

[Lennart Poettering]

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] timed out waiting for device dev-disk-by\x2duuid

[Lennart Poettering]

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] remounting root fs outside containers as MS_SHARED

[Lennart Poettering]

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] [PATCH] RFC/fsck: Allow to specify the fsck repair option in the cmdline

[Lennart Poettering]

On Thu, 15.05.14 19:07, Holger Freyther (hol...@freyther.de) wrote:

> From: Holger Hans Peter Freyther 
> 
> 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

[Ani Sinha]

On Thu, May 15, 2014 at 3:25 AM, Lennart Poettering
 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

[systemd-devel] [PATCH] RFC/fsck: Allow to specify the fsck repair option in the cmdline

[Holger Freyther]

From: Holger Hans Peter Freyther 

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 @@
 
 
 
+fsck.repair=
+
+
+Parameter understood by
+the file system checker
+services. For details, see
+
systemd-fsck@.service8.
+
+
+
+
 
quotacheck.mode=
 
 
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.
 
+
+
+fsck.repair=
+
+One of
+preen,
+yes,
+no. Controls the
+mode of operation. The default is 
+preen, and will automatically repair
+problems that can be safely fixed. yes
+ will answer yes to all questions by
+fsck and no will answer no 
to
+all questions.
+
+
 
 
 
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] [PATCH] Reset the context of /run/user/UID to the default. Bug #1097901.

[Lennart Poettering]

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

Re: [systemd-devel] [PATCH] network: fix build failure, missing KMOD_XXX flags

[Tom Gundersen]

On Thu, May 15, 2014 at 6:52 PM, Lennart Poettering
 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: . 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.

[Miroslav Grepl]

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

[Lennart Poettering]

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] Journal rotation and notifying users

[Lennart Poettering]

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] inconsistency between hibernate-multiple-sessions and suspend-multiple-sessions

[Lennart Poettering]

On Thu, 15.05.14 02:35, Michael Biebl (mbi...@gmail.com) wrote:

> 2014-05-15 2:29 GMT+02:00 Michael Biebl :
> > 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
> → yes
> 
> org.freedesktop.login1.hibernate-multiple-sessions
> → auth_admin_keep
> 
> 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] cryptsetup vs. swapon/fsck (some kind of race condition)

[Lennart Poettering]

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] [PATCH] Reset the context of /run/user/UID to the default. Bug #1097901.

[Lennart Poettering]

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] [PATCH] core: add startup resource control option

[WaLyong Cho]

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

[systemd-devel] [PATCH] core: add startup resource control option

[WaLyong Cho]

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 
.
   
 
   
+
StartupCPUShares=weight
+
+
+  Similar to CPUShares=. However,
+  only be assigned on startup state. After finishing startup, will be
+  re-assigned by CPUShares=. If
+  CPUShares= is not specified, then it will be
+  assigned to default(1024).
+
+  
+
+  
 MemoryAccounting=
 
 
@@ -241,6 +253,18 @@ along with systemd; If not, see 
.
   
 
   
+
StartupBlockIOWeight=weight
+
+
+  Similar to BlockIOWeight=. However,
+  only be assigned on startup state. After finishing startup, will be
+  re-assigned by BlockIOWeight=. If
+  BlockIOWeight= is not specified, then it will be
+  assigned to default(1000).
+
+  
+
+  
 BlockIODeviceWeight=device 
weight
 
 
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 cgroup_context_apply(CGroupContext *c, 
CGroupControllerMask mask, const cha
 char buf[MAX(DECIMAL_STR_MAX(unsigned long), 
DECIMAL_STR_MAX(usec_t)) + 1];
 usec_t q;
 
-sprintf(buf, "%lu\n", c->cpu_shares);
+sprintf(buf, "%lu\n", manager_state(m) == MANAGER_STARTING
+? c->startup_cpu_shares
+: c->

Re: [systemd-devel] remounting root fs outside containers as MS_SHARED

[Djalal Harouni]

On Wed, May 14, 2014 at 10:17:59PM -0700, Ani Sinha wrote:
> >>
> >> Why pivot_root() fails ?
> >
> > pivot_root() fails because of the following code in linux kernel :
> >
> > http://lxr.free-electrons.com/source/fs/namespace.c#L2730
> >
> > any code that calls pivot_root() under / will fail with EINVAL.
> >
> 
> This is the redhat bug that discusses the kernel behavior :
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=847418
Lennart pointed to solution that handles bug 847418:
http://cgit.freedesktop.org/systemd/systemd/tree/src/core/switch-root.c

> So what is the position here? Do we have to live with a broken
> pivot_root() with this systemd change?

IMHO since this is chroot code, you should do after the unshare() mount
namespace:
mount(NULL, "/", NULL, MS_SLAVE|MS_REC, NULL)
mount(new_root, new_root, "bind", MS_BIND|MS_REC, NULL)
...

These two solutions should work for you!

-- 
Djalal Harouni
http://opendz.org
___
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

[Zbigniew Jędrzejewski-Szmek]

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
>  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  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 
> >  #include 
> >
> > +#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] Reset the context of /run/user/UID to the default. Bug #1097901.

[Miroslav Grepl]

---
 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] [PATCH] Fix typos in systemctl manpage

[Tom Gundersen]

Applied. Thanks!

Tom

On Thu, May 15, 2014 at 1:11 PM, Eelco Dolstra
 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 
> .
>safe option to request an immediate reboot. If
>--force 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 --force twice
>with any of these operations might result in data
>loss.
> @@ -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
>  --runtime option to only mask temporarily
> -until the next reoobt of the system.
> +until the next reboot of the system.
>
>  
>
> @@ -1425,7 +1425,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
> systemd-udevd.service
>  
>Parameter Syntax
>
> -  Unit ommands listed above take either a single unit name
> +  Unit commands listed above take either a single unit name
>(designated as NAME), or multiple
>unit specifications (designated as
>PATTERN...). 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] Fix typos in systemctl manpage

[Eelco Dolstra]

---
 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 
.
   safe option to request an immediate reboot. If
   --force 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 --force twice
   with any of these operations might result in data
   loss.
@@ -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
 --runtime option to only mask temporarily
-until the next reoobt of the system.
+until the next reboot of the system.
   
 
 
@@ -1425,7 +1425,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
systemd-udevd.service
 
   Parameter Syntax
 
-  Unit ommands listed above take either a single unit name
+  Unit commands listed above take either a single unit name
   (designated as NAME), or multiple
   unit specifications (designated as
   PATTERN...). 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] remounting root fs outside containers as MS_SHARED

[Lennart Poettering]

On Wed, 14.05.14 15:12, Ani Sinha (a...@arista.com) wrote:

> 
> On Wed, May 14, 2014 at 9:14 AM, Lennart Poettering
>  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

Re: [systemd-devel] Start-up resource and prioritization control

[Tom Gundersen]

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
 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] cryptsetup vs. swapon/fsck (some kind of race condition)

[Andy Kittner]

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] systemd freezes after rshd execution, if network connection is down

[Jimmy Assarsson]

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
 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  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 
>  #include 
>
> +#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)

[Kay Sievers]

On Thu, May 15, 2014 at 2:30 AM, Andy Kittner  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] [PATCH] Fix systemd-stdio-bridge symlink

[Umut Tezduyar Lindskog]

On Wed, May 14, 2014 at 1:05 PM, Colin Guthrie  wrote:
> 'Twas brillig, and Umut Tezduyar Lindskog at 13/05/14 18:37 did gyre and
> gimble:
>>
>>
>> On Wednesday, May 7, 2014, Colin Guthrie > > 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] [RFC PATCH] Fix so install will work without 'ln --relative' support

[Umut Tezduyar Lindskog]

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  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: