Re: [systemd-devel] udev 215 creates inactive MD devices upon stopping them

[NeilBrown]

On Thu, 24 Jul 2014 23:53:30 +0200 Kay Sievers  wrote:

> On Thu, Jul 24, 2014 at 5:48 PM, Sebastian Parschauer
>  wrote:
> 
> > as discussed on linux-raid, please fix the bug that udev 215 creates
> > inactive MD devices upon stopping them.
> >
> > Reference: http://www.spinics.net/lists/raid/msg46676.html
> > Reported-by: Francis Moreau 
> >
> > An open() call to /dev/mdX after creating it with mknod is enough to
> > create such inactive MD device.
> >
> > According to Artur the issue is caused by this change in udev:
> >
> >> commit 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
> >> Author: Kay Sievers 
> >> Date:   Sun Apr 13 19:54:27 2014 -0700
> >>
> >>  udev: serialize/synchronize block device event handling with file 
> >> locks
> >>
> >> http://cgit.freedesktop.org/systemd/systemd/commit/?id=3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
> >>
> >> It seems that they have already disabled this for dm for some reason,
> >> but not for md:
> >>
> >> commit e918a1b5a94f270186dca59156354acd2a596494
> >> Author: Kay Sievers 
> >> Date:   Tue Jun 3 16:49:38 2014 +0200
> >>
> >> udev: exclude device-mapper from block device ownership event locking
> >>
> >> http://cgit.freedesktop.org/systemd/systemd/commit/?id=e918a1b5a94f270186dca59156354acd2a596494
> 
> MD devices are excluded now from the locking logic, like dm devices already 
> are.
> 
> Instantiation of devices at open() is incompatible with udev's locking
> logic. That feature is not useful on most systems today, mknod()
> should never be done by any tools, only by the kernel itself. It
> should probably be disabled by default.

I agree that instantiating on open is an unfortunate design, but it has been
around for a long time so we cannot just ignore it or turn it off.
I have a new approach to creating md device which we might eventually be able
to transition too, and then maybe deprecate the old way.
In the mean time, thanks for teaching udev to put up with md's peculiarities.

NeilBrown


> 
> (The locking scheme is used to support partitioning programs, to make
> sure udev will not interfere with the partitioning tool while it
> creates/removes partitions. As long as an exclusive lock is held on
> the disk device node, all udev events are suppressed, the close() of
> the disk which war opened for writing will re-read the partition table
> and synthesize all suppressed udev events for the partitions again.)
> 
> Thanks,
> Kay
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Changing configurations with networkd

[Tom Gundersen]

On Thu, Jul 24, 2014 at 10:54 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Thu, Jul 24, 2014 at 09:18:14PM +0200, Tom Gundersen wrote:
>> A quick fix would be to set
>>
>> /proc/sys/net/ipv4/conf/all/promote_secondaries
>>
>> to 1.
> Wouldn't it be nice to set it to 1 always. The default setting of 0
> is a brain damaged trap.

Yeah, I have been trying to find some info about why one might want it
to be 0, to me it makes no sense at all. So far I found no reasons to
keep this default, so unless someone has any new info I'll flip the
switch.

Cheers,

Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev 215 creates inactive MD devices upon stopping them

[Kay Sievers]

On Thu, Jul 24, 2014 at 5:48 PM, Sebastian Parschauer
 wrote:

> as discussed on linux-raid, please fix the bug that udev 215 creates
> inactive MD devices upon stopping them.
>
> Reference: http://www.spinics.net/lists/raid/msg46676.html
> Reported-by: Francis Moreau 
>
> An open() call to /dev/mdX after creating it with mknod is enough to
> create such inactive MD device.
>
> According to Artur the issue is caused by this change in udev:
>
>> commit 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
>> Author: Kay Sievers 
>> Date:   Sun Apr 13 19:54:27 2014 -0700
>>
>>  udev: serialize/synchronize block device event handling with file locks
>>
>> http://cgit.freedesktop.org/systemd/systemd/commit/?id=3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
>>
>> It seems that they have already disabled this for dm for some reason,
>> but not for md:
>>
>> commit e918a1b5a94f270186dca59156354acd2a596494
>> Author: Kay Sievers 
>> Date:   Tue Jun 3 16:49:38 2014 +0200
>>
>> udev: exclude device-mapper from block device ownership event locking
>>
>> http://cgit.freedesktop.org/systemd/systemd/commit/?id=e918a1b5a94f270186dca59156354acd2a596494

MD devices are excluded now from the locking logic, like dm devices already are.

Instantiation of devices at open() is incompatible with udev's locking
logic. That feature is not useful on most systems today, mknod()
should never be done by any tools, only by the kernel itself. It
should probably be disabled by default.

(The locking scheme is used to support partitioning programs, to make
sure udev will not interfere with the partitioning tool while it
creates/removes partitions. As long as an exclusive lock is held on
the disk device node, all udev events are suppressed, the close() of
the disk which war opened for writing will re-read the partition table
and synthesize all suppressed udev events for the partitions again.)

Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] analyze: fix seg-fault with no cl-argument

[Daniel Buch]

We need to check if argv[1] is set before compare
---
 src/analyze/analyze.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/analyze/analyze.c b/src/analyze/analyze.c
index 66e2aab..83da7f5 100644
--- a/src/analyze/analyze.c
+++ b/src/analyze/analyze.c
@@ -1349,7 +1349,7 @@ int main(int argc, char *argv[]) {
 if (r <= 0)
 goto finish;
 
-if (streq(argv[optind], "verify"))
+if (argv[optind] && streq(argv[optind], "verify"))
 r = verify_units(argv+optind+1,
  arg_user ? SYSTEMD_USER : SYSTEMD_SYSTEM,
  arg_man);
-- 
2.0.2

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Changing configurations with networkd

[Kay Sievers]

On Thu, Jul 24, 2014 at 10:54 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Thu, Jul 24, 2014 at 09:18:14PM +0200, Tom Gundersen wrote:
>> A quick fix would be to set
>>
>> /proc/sys/net/ipv4/conf/all/promote_secondaries
>>
>> to 1.
> Wouldn't it be nice to set it to 1 always. The default setting of 0
> is a brain damaged trap.

We flip a few defaults with our sysctl file already. If it is the
right thing to do, we can just add that there.

Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Changing configurations with networkd

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jul 24, 2014 at 09:18:14PM +0200, Tom Gundersen wrote:
> A quick fix would be to set
> 
> /proc/sys/net/ipv4/conf/all/promote_secondaries
> 
> to 1.
Wouldn't it be nice to set it to 1 always. The default setting of 0
is a brain damaged trap.

Zbyszek

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 7/7] connection: fix user quota accounting corruption

[Djalal Harouni]

Hi,

It seems there is still another bug in the use/caculation of
conn->msg_users_max, will send another patch on top of this.

On Wed, Jul 23, 2014 at 10:19:11PM +0100, Djalal Harouni wrote:
> First use kzalloc to allocate the users array, so we do not reference
> unintialized values.
> 
> And free the old conn->msg_users array not the newly allocated 'users'
> one.
> 
> Patch tested, and users will hit the KDBUS_CONN_MAX_MSGS_PER_USER limit
> and fail with -ENOBUFS
> 
> Signed-off-by: Djalal Harouni 
> ---
>  connection.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/connection.c b/connection.c
> index c432286..a2ed645 100644
> --- a/connection.c
> +++ b/connection.c
> @@ -634,13 +634,13 @@ static int kdbus_conn_queue_user_quota(struct 
> kdbus_conn *conn,
>   unsigned int i;
>  
>   i = 8 + KDBUS_ALIGN8(user);
> - users = kmalloc(sizeof(unsigned int) * i, GFP_KERNEL);
> + users = kzalloc(sizeof(unsigned int) * i, GFP_KERNEL);
>   if (!users)
>   return -ENOMEM;
>  
>   memcpy(users, conn->msg_users,
>  sizeof(unsigned int) * conn->msg_users_max);
> - kfree(users);
> + kfree(conn->msg_users);
>   conn->msg_users = users;
>   conn->msg_users_max = i;
>   }
> -- 
> 1.9.3
> 

-- 
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] Changing configurations with networkd

[Tom Gundersen]

On Thu, Jul 24, 2014 at 5:59 PM, Michael Olbrich
 wrote:
> On Thu, Jul 24, 2014 at 02:05:24PM +0200, Marcel Holtmann wrote:
>> > Right, I spoke too quickly. What I don't want is to preserve state
>> > between reboots, preserving it between restarts of networkd would
>> > indeed be fine. We already serialize the dhcp leases to /run, so I'd
>> > be happy to take a patch to deserialize these again when networkd
>> > starts.
>>
>> I am not sure this is useful either. It feels like a bandaid for the time
>> where networkd does not have an API to reload configuration changes. Killing
>> networkd should give you a clean start from the configuration files and not
>> magic cached value somewhere. Otherwise you end up with funny side effects
>> all the time and have to explain to users to clear some /run states. Or ask
>> them "to switch the computer off and back on again".
>>
>> When you are opting for DHCP instead of static addresses, then there is
>> really no guarantee for addresses staying the same. At least not for the
>> client to know. So unless you own the DHCP server and configure it with
>> static assignment. In all cases you have to confirm with the DHCP server that
>> you address is still valid.
>
> Getting a new IP address is not the biggest problem. But right now, when
> the valid_lft for the _old_ address is over, then then _new_ address is
> removed as well and the interface has no address at all! That is not
> acceptable. I can live with a different new address for now, but not with
> no address at all.

Indeed, this needs to be fixed. A quick fix would be to set

/proc/sys/net/ipv4/conf/all/promote_secondaries

to 1.


Cheers,

Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Networkd dhcp hostname override

[Thomas Suckow]

Now that networkd can send the systems hostname to the dhcp server, I would 
find it useful to have an option to override the hostname that gets sent.

In my use case, I would like to setup a number of macvlans with different 
hostnames.

Something as simple as

[DHCP]
SendHostname=true
Hostname=foo

Regards,
Thomas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Forward from linux-raid@ ML: systemd-215 creates inactive MD devices upon stopping them

[Samuli Suominen]

Forwarding to systemd-devel@ for
http://bugs.gentoo.org/show_bug.cgi?id=517986


 Original Message 
Subject:Re: udev 215 creates inactive MD devices upon stopping them
Date:   Thu, 24 Jul 2014 17:48:05 +0200
From:   Sebastian Parschauer 
To: systemd-de...@freedesktop.org, Kay Sievers 
CC: Linux RAID ,
artur.paszkiew...@intel.com, Francis Moreau 



[resending to the correct mailing list]

Hi,

as discussed on linux-raid, please fix the bug that udev 215 creates
inactive MD devices upon stopping them.

Reference: http://www.spinics.net/lists/raid/msg46676.html
Reported-by: Francis Moreau 

An open() call to /dev/mdX after creating it with mknod is enough to
create such inactive MD device.

According to Artur the issue is caused by this change in udev:

> commit 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
> Author: Kay Sievers 
> Date:   Sun Apr 13 19:54:27 2014 -0700
>
>  udev: serialize/synchronize block device event handling with file locks
>
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
>
> It seems that they have already disabled this for dm for some reason,
> but not for md:
>
> commit e918a1b5a94f270186dca59156354acd2a596494
> Author: Kay Sievers 
> Date:   Tue Jun 3 16:49:38 2014 +0200
>
> udev: exclude device-mapper from block device ownership event locking
>
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=e918a1b5a94f270186dca59156354acd2a596494
>

Thanks,
Sebastian


--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Changing configurations with networkd

[Michael Olbrich]

On Thu, Jul 24, 2014 at 02:05:24PM +0200, Marcel Holtmann wrote:
> > Right, I spoke too quickly. What I don't want is to preserve state
> > between reboots, preserving it between restarts of networkd would
> > indeed be fine. We already serialize the dhcp leases to /run, so I'd
> > be happy to take a patch to deserialize these again when networkd
> > starts.
> 
> I am not sure this is useful either. It feels like a bandaid for the time
> where networkd does not have an API to reload configuration changes. Killing
> networkd should give you a clean start from the configuration files and not
> magic cached value somewhere. Otherwise you end up with funny side effects
> all the time and have to explain to users to clear some /run states. Or ask
> them "to switch the computer off and back on again".
> 
> When you are opting for DHCP instead of static addresses, then there is
> really no guarantee for addresses staying the same. At least not for the
> client to know. So unless you own the DHCP server and configure it with
> static assignment. In all cases you have to confirm with the DHCP server that
> you address is still valid.

Getting a new IP address is not the biggest problem. But right now, when
the valid_lft for the _old_ address is over, then then _new_ address is
removed as well and the interface has no address at all! That is not
acceptable. I can live with a different new address for now, but not with
no address at all.

Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] crypttab automount

[Ralf Jung]

Hi,

>> Essentially, I want a proper mount with the usual RequiredBy and
>> WantedBy - but without the Before that makes others wait on this disk.
>> So, the concurrency part of automount is exactly what I want, but
>> without the on-demand part. Is that possible?
> 
> You're looking for "nofail" without the noauto (I think) (again in man
> crypttab).

I did that for both crypttab and fstab, and
now the behaviour is exactly what I want. Great. Thanks a lot :)

It seems my local manpage is outdated, I had to go to
 to learn
about this option (and the nofail description in fstab doesn't say
anything about concurrency - naturally, it probably predates systemd ;-)

Kind regards
Ralf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sysusers and login.defs checks

[Colin Guthrie]

Colin Guthrie wrote on 24/07/14 13:32:
> If direct
> parsing is NAKed perhaps it could just shell out to a
> systemd-sysusers-getnewuserdetails command which spat out a uid:gid pair
> (and took an optional --system argument), that way the parsing logic
> only needs to live in one place.

This bit, of course, is braindead! If this is done at all, it should be
via an API in libsystemd. I think my brain was suggesting that a binary
was somehow OK if such a library API didn't want to be officially
blessed, but that's just broken reasoning - such a binary is an API as
much as a library call would be.

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] [PATCH] syslog: apply requested datagram size before sysctl

[Kay Sievers]

On Thu, Jul 24, 2014 at 10:53 AM, Umut Tezduyar Lindskog
 wrote:
> systemd-sysctl runs after syslog.socket since syslog.socket
> has DefaultDependencies=no. Due to this, syslog.socket
> is created with default value of net.unix.max_dgram_qlen.
> ---
>  units/syslog.socket |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/units/syslog.socket b/units/syslog.socket
> index e6e9cf8..4e23953 100644
> --- a/units/syslog.socket
> +++ b/units/syslog.socket
> @@ -16,6 +16,7 @@ Before=sockets.target shutdown.target
>  Conflicts=shutdown.target
>
>  [Socket]
> +ExecStartPre=/usr/lib/systemd/systemd-sysctl 
> --prefix=/proc/sys/net/unix/max_dgram_qlen

We should avoid execing binaries from default configuration like this.
Things should be fixed where they are broken.

The kernel needs a way to set that value, and we should introduce a
per-socket config option to be used in this file instead.

Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sysusers and login.defs checks

[Colin Guthrie]

Lennart Poettering wrote on 24/07/14 11:59:
> ...
> snip
> ...
> I am pretty sure you will find people who will defend some of this
> non-sense, but honestly, this is all is stuff that shouldn't exist.

OK, that was a fairly convincing message! Many thanks for taking the
time and being so explicit.

I now appreciate why the journal/coredump splitting is desirable and why
it can/should be different from the sysusers range (and from each other
too).


That said, I'm still not convinced that it should be a simple setting in
journald.conf only. If a package wants to install a service with it's
own user and explicitly wants it to have it's own journal (is apache
httpd a good example of this? Dunno, but it's conceivable either way!),
then they would need the appropriate sysusers.d snippet but then they'd
also have to either manipulate the journald.conf file's SplitUserRange
line or use a dropin file that some generator uses to manipulate and
configure the line accordingly. This just feels a bit too clunky.

Would there be a a way to somehow keep SplitUserRange for basic
(administrator) overrides, but also parse e.g. a column in the sysusers
file to specify whether or not that user wants it's own journal [and
another column for coredump]? The SplitUserRange setting could have
syntax that allowed the admin to either extend the info found in
sysusers (which would be the default), or explicitly override some
setting. e.g.

Say I wanted a split journal for UID 99 (a manually created system
user), I could just say:

  SplitUserRange=99

and all the packaged preferences in sysusers files would still be
honoured in addition to UID 99.

If the sysusers file for apache's httpd had:

  u httpd 440 "HTTP User" y

where "y" is the new "split journal" column, but I, as an admin, wanted
to override that, I could just specify:

  SplitUserRange=99,-440

The leading "-" means "remove range".

Of course an alternative would be to just override the sysusers file in
/etc and put an "n" instead of the "y" (or leave it out), but there may
be a desire for the admin to override all the journal splitting easily
by doing something like:

  SplitUserRange=-1-65535
or
  SplitUserRange=-*



It's maybe crossing a boundary (i.e. journald should maybe not be
parsing sysuser's config files?), but it would certainly simplify
packaging and avoid the need for the "config patching generator thingy".



Iff it's OK to parse sysusers config from journal [and coredump] stuff,
then perhaps it's also OK to parse it from shadow-utils? If so, then
this is one step closer to your goal of killing login.defs. If direct
parsing is NAKed perhaps it could just shell out to a
systemd-sysusers-getnewuserdetails command which spat out a uid:gid pair
(and took an optional --system argument), that way the parsing logic
only needs to live in one place. This is obviously pretty racey, but I
guess shadow-utils should really do some kind of locking on the files
anyway. I've no idea if/how all of this would work when hooking things
up to e.g. LDAP (I'm not even sure adduser+friends can do that?)


I guess my main concern still remains that uid range settings for system
users would now be in two places - one used by sysusers and another by
adduser (I now accept your argument that the other two places are
different configuration data even if it's conceptually similar). I want
to be able to tell a user that the configuration is in one place not
explain that package "system users ranges" are in one place and
adduser's "system user range" is in another.

Of course I'm assuming here that shadow-utils and it's adduser commands
are still expected to be around for a while... perhaps this is
considered legacy too these days (not sure what the replacement would be
tho'!)?


Sorry if this thread is getting a bit annoying, but I am convinced by
most of the arguments now!

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

[systemd-devel] Fwd: race conditions after SIGTERM

[Reindl Harald]

maybe that's a systemd thing

i know Fedora 19 has not a recent systemd but the question
remains if systemctl in case of "Type=simple" may act the same
way while stop a service as for starting - send the SIGTERM
and immediately return while the binary still writes data

that could explain race conditions like below

* stop mysqld instance 1
* stop mysqld instance 2
* the services still flush data but "systemctl" already returned
* rsync both datadir
* corruption

 Original-Nachricht 
Betreff: race conditions after SIGTERM
Datum: Thu, 24 Jul 2014 12:42:51 +0200
Von: Reindl Harald 
An: Mailing-List mariadb <"maria-discuss"@lists.launchpad.net>

how can that script lead to a race condition where files
are not fully written to disk? that never happens if the
systemd-unit for the replication instance has
"ExecStopPost=/usr/bin/sleep 1" and waits a while

my only explaination is that mysqld returns after the SIGTERM
from systemd before all data are completly written in some racy
situations and so rsynced incompletly to the datadir of the
other instance
_

#!/bin/bash
systemctl stop replication.service
systemctl stop mysqld.service
rsync $RSYNC_PARAMS /mysql_replication/ /mysql_data/
systemctl start replication.service
systemctl start mysqld.service
_

[Unit]
Description=MariaDB Replication

[Service]
Type=simple
PIDFile=/run/mysqld/mysqld_replication.pid
ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my-replication.cnf 
--pid-file=/run/mysqld/mysqld_replication.pid
--socket=/var/lib/mysql/mysql_replication.sock --open-files-limit=3 
--basedir=/usr --user=mysql
Environment="LANG=en_GB.UTF-8"
Restart=always
RestartSec=1
_

140724 12:22:59 [Note] /usr/libexec/mysqld: Shutdown complete
140724 12:23:01 [Note] Plugin 'InnoDB' is disabled.
Cannot find checkpoint record at LSN (1,0x35767)
140724 12:23:01 [ERROR] mysqld: Aria recovery failed. Please run aria_chk -r on 
all Aria tables and delete all
aria_log. files
140724 12:23:01 [ERROR] Plugin 'Aria' init function returned error.
140724 12:23:01 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.
140724 12:23:01 [Note] Plugin 'FEDERATED' is disabled.
140724 12:23:01 [Note] Plugin 'FEEDBACK' is disabled.
140724 12:23:01 [ERROR] Aria engine is not enabled or did not start. The Aria 
engine must be enabled to continue as
mysqld was configured with --with-aria-tmp-tables
140724 12:23:01 [ERROR] Aborting
140724 12:23:01 [Note] /usr/libexec/mysqld: Shutdown complete
140724 12:23:03 [Note] Plugin 'InnoDB' is disabled.
Cannot find checkpoint record at LSN (1,0x35767)



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Changing configurations with networkd

[Brendan Hide]

On 24/07/14 10:49, Tom Gundersen wrote:

On Thu, Jul 24, 2014 at 10:16 AM, Michael Olbrich
 wrote:

On Wed, Jul 23, 2014 at 04:46:26PM +0200, Marcel Holtmann wrote:


There is no mandate that the server has to give you the same address
after 10 minutes when you ask again. It is valid to just get a different one.
And that many home routers try to give you back the same one does not mean
that they are required to do so.

[snip]


What is causing your DHCP server to send out a different
IP address later on, I don't know, but it seems unlikely that this is
anything we can fix in the client.


As Marcel says, the DHCP server behaviour of giving a different IP is perfectly normal 
behaviour. Once the lease is expired the DHCP server's only obligation is to give a 
"valid" config - it doesn't have to be the same. Based on the information 
given, networkd isn't taking the right action.

A peripheral issue with this thread is that I don't see any mention of a "reload" option. A 
graceful zero-to-minimal-downtime "reload" should cater for Michael's use-case of manual changes to 
the "static" config files. Of course I haven't checked if this is already supported. ;)

I see a couple of choices here with regards to the restart/stop-start situation:
a) What *seems* to be the direction in this thread: Don't tear down, save the 
state, re-attempt same lease (keeps config functional when the daemon is 
stopped; not standards-compliant; doesn't fit with previous paradigms)
b) tear down on stop, save state, rebuild on start (robust; less "musical 
chairs"; downtime)

Technically I see b) as the right choices. The reasoning to me is twofold:
1) The alternative would violate standards: A DHCP lease might end after the 
daemon has stopped and the network is not going to automatically deconfigure. 
For static configs this is less of an issue.
2) The "standard" paradigm for most (all?) of the network{,ing} services for 
any current or previous *nix I've seen is that a stop or restart tears down the 
configuration.

--
__
Brendan Hide
http://swiftspirit.co.za/
http://www.webafrica.co.za/?AFF1E97

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Changing configurations with networkd

[Marcel Holtmann]

Hi Tom,

>> I think the lease should be remembered and reused in this case.
> 
> Hm, this sounds like a bug somewhere. When the new discover is sent
> out it should send the same identifying information to the server, and
> hence be given the same lease back again. Wireshark should tell you if
> the fault is networkd's or the DHCP server.
 
 I get the same address at first, but after several minutes the DHCP server
 decides to offer a new address. I should note, that I have a 10 minute
 lease time for debugging purposes, so that might make the problem more
 prominent. I'll see if I can figure out what happens here.
>>> 
>>> look at your DHCP server and see what lease time it really hands out after 
>>> reboot.
>>> 
>>> However this is between you and your DHCP server. If you configure a lease
>>> time of 10 minutes, then that is the only guaranteed time for a given IP
>>> address. There is no mandate that the server has to give you the same 
>>> address
>>> after 10 minutes when you ask again. It is valid to just get a different 
>>> one.
>>> And that many home routers try to give you back the same one does not mean
>>> that they are required to do so.
>>> 
>>> The nice DHCP servers will remember your Ethernet address and/or identity
>>> information and give you back your old IP address. Either with the left over
>>> lease time or with a brand new lease time. There is really no need to store
>>> this information on disk. If the lease expired the information on disk are
>>> stale as well. And since our DHCP implementation is so fast, it makes really
>>> no difference.
>>> 
>>> It is safer start out with a brand new DHCP lease instead of having to deal
>>> with renewal during boot. At least that way you know the DHCP server is 
>>> still
>>> there and you have a valid IP address. Just re-using a stored IP with a
>>> left-over lease is not safe anyway. You never know what changed in the
>>> network when you were off.
>> 
>> I think there was some misunderstanding here. I don't want to keep the
>> lease across reboots. I don't care about that. I think networkd should
>> remember the lease when restarting networkd only and not send a new dhcp
>> discover.
> 
> Right, I spoke too quickly. What I don't want is to preserve state
> between reboots, preserving it between restarts of networkd would
> indeed be fine. We already serialize the dhcp leases to /run, so I'd
> be happy to take a patch to deserialize these again when networkd
> starts.

I am not sure this is useful either. It feels like a bandaid for the time where 
networkd does not have an API to reload configuration changes. Killing networkd 
should give you a clean start from the configuration files and not magic cached 
value somewhere. Otherwise you end up with funny side effects all the time and 
have to explain to users to clear some /run states. Or ask them "to switch the 
computer off and back on again".

When you are opting for DHCP instead of static addresses, then there is really 
no guarantee for addresses staying the same. At least not for the client to 
know. So unless you own the DHCP server and configure it with static 
assignment. In all cases you have to confirm with the DHCP server that you 
address is still valid.

> That said, I'm not sure this will help you much in your case. It would
> allow us to explicitly request the current IP address when restarting
> networkd, but according to your previous email you already are getting
> assigned the correct IP address at first, and then only later does
> this change. What is causing your DHCP server to send out a different
> IP address later on, I don't know, but it seems unlikely that this is
> anything we can fix in the client.

I have my doubts as well here. Seems like a misconfigured DHCP server.

Regards

Marcel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sysusers and login.defs checks

[Lennart Poettering]

On Wed, 23.07.14 21:22, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> > Does this make sense?
> 
> To be frank, I really don't think it does make much sense at all. I
> mean, something which is currently configured in one place and then
> used

Well, no, it's not the same setting that is configured at three
places. It's different things you configure. There's conceptually quite
a difference between these settings:

 a) Numeric UID boundary

and
 
 1. ranges sysusers dynamically picks UIDs from
 2. ranges where journald splits up journals
 3. ranges where coredump grant users access to their own coredumps

While #1 configures the part that by default is the bit "below" the UID
boundray, #2 + #4 configure the part that by default is "above" the UID
boundary.

Also, we allow people to actually take benefit of this. As mentioned in
that other mail, being able to configure which users precisely get split
up journal files can be truely useful...

The tools that made use of the UID boundary actually derived very
different things from it. sysusers defined the range to pick dynamic UIDs
from as 1..BOUNDARY. journald picked the range to split of journals
for as BOUNDARY+1..MAXINT-3. The former was simple but not even correct for
Debian nor Fedora. The latter is probably what we should do, but don't
even do (because the "nobody" user shouldn'get his private journal file).

With making the respective ranges explicitly configurable we hence allow
distributions to properly enforce their own policies, and we add true
value to admins. All that while not blessing the crufty /etc/login.defs
file as something we officially want to support in legacy-free systems.

The more I think about all of this the more I actually get convinced
that making the ranges explicitly configurable for their respective
purpose is the right thing to do. I mean, the concept of numeric 32bit
UIDs on UNIX is seriously broken, in particular when it comes to
assigning meaning to specific ranges. Any better designed OS would have
used a namespace that requires no explicit managing (such as UUIDs), and
defined context via true metadata about the users, rather than
mathematical range expressions.

Now, because the namespace is so small, and because semantics have to be
derived from the numeric range a UID is in, I really find it beneficial
if we expose all that logic to the admin/vendor/user, then to strictly
enforce a way too simple view on things, where everything below some
value is one thing and everything above is another thing. In particular
since such a model cannot cover the special cases of UID 0, MAXINT-1,
MAXINT-2.

We have seen now that Debian defines at least 5 ranges with specific
semantics, and Fedora has at least 3 too. In the future we'll probably
see even more ranges, for example for dynamic UID allocation for things
like containers. Trying to cram this all into a single value can never
work.

Or to make this more explicit: somewhere on my TODO list is adding a
mini daemon and NSS module that can dynamically hand out UID ranges for
tools like nspawn for usage in UID namespacing. That daemon would also
have a configuration file. In that configuration file we'd have to
configure an explicit range it shall use. That range is probably going
to be something like 4-5 by default, i.e. very far away from the
boundary...

> in tools such as shadow-utils when creating users (both with and without
> -s) now has to be configured in three *additional* places. That hardly
> seems like an improvement and sounds like a recipe for misconfiguration.
> It just makes it more convoluted, where essentially the same data is
> repeated in multiple places and then you have some crazy config file
> patching system on top of that to distribute it to all those places.

It's very different data actually.

> If you were to suggest some new shared configuration file and we could
> update shadow-utils and friends to use it then fine (seems kinda
> pointless tho'), but I really don't get the logic here.

Well, login.defs might have configuration options to tell adduser from
which range to allocate regular and system users from, but it doesn't
have options to configure in which ranges to split up journal files,
in which ranges to provide access to your own coredump files, and from
which ranges to allocate dynamic throw-away UIDs for user namespacing
from. And it shouldn't have, as much of that is logic specific to the
subsystem, and is not orthogonal (by which I mean, that where to split
up journal files might or might not have overlapping ranges with where
to allocate system users from, if you follow what i mean).

> I'd rather we just refactored systemd to have a utility function
> "is_system_uid()" or such like which just does the compiled in default
> check as it does now (no functional change to how it works now, just
> centralised) and then I can just hack in reading and honouring
> login.defs into that utility function in a downstream patch. It would be
>

Re: [systemd-devel] [PATCH] syslog: apply requested datagram size before sysctl

[Umut Tezduyar Lindskog]

On Thu, Jul 24, 2014 at 11:30 AM, Colin Guthrie  wrote:
> Umut Tezduyar Lindskog wrote on 24/07/14 09:53:
>> systemd-sysctl runs after syslog.socket since syslog.socket
>> has DefaultDependencies=no. Due to this, syslog.socket
>> is created with default value of net.unix.max_dgram_qlen.
>> ---
>>  units/syslog.socket |1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/units/syslog.socket b/units/syslog.socket
>> index e6e9cf8..4e23953 100644
>> --- a/units/syslog.socket
>> +++ b/units/syslog.socket
>> @@ -16,6 +16,7 @@ Before=sockets.target shutdown.target
>>  Conflicts=shutdown.target
>>
>>  [Socket]
>> +ExecStartPre=/usr/lib/systemd/systemd-sysctl 
>> --prefix=/proc/sys/net/unix/max_dgram_qlen
>>  ListenDatagram=/run/systemd/journal/syslog
>>  SocketMode=0666
>>  PassCredentials=yes
>
>
> Not sure if there are other problems here, but IMO it would be safer to
> make this an ExecStartPre=- thing as we presumably don't want the syslog
> socket to fail just because we couldn't run sysctl for whatever reason
> (not that I could think why, unless it fails when proc is ro or such
> like - not checked)

Hi,

I think you have a great point.

Umut

>
> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sysusers and login.defs checks

[Lennart Poettering]

On Wed, 23.07.14 20:50, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> 
> On Wed, Jul 23, 2014 at 07:31:31PM +0200, Lennart Poettering wrote:
> 
> [snip]
> 
> > Now, this alone wouldn't provide compatibility with the dreaded
> > login.defs file. For that we'd then employ a postinst script that reads
> > the range from the file, and then automatically generates a sysuers.d
> > drop-in or a patches journald.conf and coredump.conf should the range
> > not match the default.
> > 
> > Does this make sense?
> Seems like a great big effort to avoid reading a simple configuration
> file.
> 
> When people want to teach systemd to generate dynamic configuration
> based on some other configuration, to pass commandline options and/or
> environment variables to a daemon that is starting up, because the
> daemon cannot do it on its own, we always tell them: teach the daemon
> to do that on its own. We should apply the same principle here, and
> not spread the configuration over n automatically generated files.

Well, I'd feel easier about it if I actually believed that the
configuration file login.defs was well designed and not just completely
drowned in legacy UNIX cruft... 

Also note that the additions I propose actually don't just make the
boundary configurable, but are a lot more generic than that. They make a
subsystem-specific logic configurable, that is by default sourced from
the UID boundary, but it's not the UID boundary you configure.

Hence, the nature of the configuration changed quite a bit. Instead of
making the UID boundary configurable (which I find really wrong
conceptually, because it shouldn't be the choice of the admin, but of
the vendor), we explicitly allow the logic normally based on it to be
configured, natively.

It is philosphically quite a difference whether we expose "SystemUIDMax=" as
journald.conf option or whether we expose "SplitUserRange=" as I
propose. The former would be strictly a duplication of configuration
already existing in login.defs. The latter is much more generic...

Or try to see it from a different perspective: we already introduced
multiple SplitMode= settings, since people wanted to split up non-login
user journals too (we added that on request of David Strauss). A
weakness of those models so far was that this meant that either they get
everything split up, or just the login users, which is usually much too
unprecise. Usually what's actually desired is to split out login users
plus a certain additional range of users used to run multiple httpd
instances or so. With the configuration options I propose you can do
that.

> > As a side effect this would actually even allow us to be closer to
> > FEdora's current bheaviour, since it reserves UIDs < 200 for static
> > assignment, which we could then easily exclude from theis logic, too.
> In practice this might not be useful, because even if all the 800 UIDs
> starting from 999 were used up, it would be better to encroach on the
> "static" range than to fail.

Well, hopefully the static UIDs are static for a reason: they are UIDs
that might write files to NFS accessible shares. It might be a better
choice to fail the addition of the system users than to allow the wrong
networked users access...

But anyway, I personally wouldn't bother with statically assigned UIDs,
but then again, I can understand why Fedora has the policy on this it has.

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] syslog: apply requested datagram size before sysctl

[Colin Guthrie]

Umut Tezduyar Lindskog wrote on 24/07/14 09:53:
> systemd-sysctl runs after syslog.socket since syslog.socket
> has DefaultDependencies=no. Due to this, syslog.socket
> is created with default value of net.unix.max_dgram_qlen.
> ---
>  units/syslog.socket |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/units/syslog.socket b/units/syslog.socket
> index e6e9cf8..4e23953 100644
> --- a/units/syslog.socket
> +++ b/units/syslog.socket
> @@ -16,6 +16,7 @@ Before=sockets.target shutdown.target
>  Conflicts=shutdown.target
>  
>  [Socket]
> +ExecStartPre=/usr/lib/systemd/systemd-sysctl 
> --prefix=/proc/sys/net/unix/max_dgram_qlen
>  ListenDatagram=/run/systemd/journal/syslog
>  SocketMode=0666
>  PassCredentials=yes


Not sure if there are other problems here, but IMO it would be safer to
make this an ExecStartPre=- thing as we presumably don't want the syslog
socket to fail just because we couldn't run sysctl for whatever reason
(not that I could think why, unless it fails when proc is ro or such
like - not checked)

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

[systemd-devel] [PATCH] syslog: apply requested datagram size before sysctl

[Umut Tezduyar Lindskog]

systemd-sysctl runs after syslog.socket since syslog.socket
has DefaultDependencies=no. Due to this, syslog.socket
is created with default value of net.unix.max_dgram_qlen.
---
 units/syslog.socket |1 +
 1 file changed, 1 insertion(+)

diff --git a/units/syslog.socket b/units/syslog.socket
index e6e9cf8..4e23953 100644
--- a/units/syslog.socket
+++ b/units/syslog.socket
@@ -16,6 +16,7 @@ Before=sockets.target shutdown.target
 Conflicts=shutdown.target
 
 [Socket]
+ExecStartPre=/usr/lib/systemd/systemd-sysctl 
--prefix=/proc/sys/net/unix/max_dgram_qlen
 ListenDatagram=/run/systemd/journal/syslog
 SocketMode=0666
 PassCredentials=yes
-- 
1.7.10.4

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Changing configurations with networkd

[Tom Gundersen]

On Thu, Jul 24, 2014 at 10:16 AM, Michael Olbrich
 wrote:
> On Wed, Jul 23, 2014 at 04:46:26PM +0200, Marcel Holtmann wrote:
>> Hi Michael,
>>
>> >>> I think the lease should be remembered and reused in this case.
>> >>
>> >> Hm, this sounds like a bug somewhere. When the new discover is sent
>> >> out it should send the same identifying information to the server, and
>> >> hence be given the same lease back again. Wireshark should tell you if
>> >> the fault is networkd's or the DHCP server.
>> >
>> > I get the same address at first, but after several minutes the DHCP server
>> > decides to offer a new address. I should note, that I have a 10 minute
>> > lease time for debugging purposes, so that might make the problem more
>> > prominent. I'll see if I can figure out what happens here.
>>
>> look at your DHCP server and see what lease time it really hands out after 
>> reboot.
>>
>> However this is between you and your DHCP server. If you configure a lease
>> time of 10 minutes, then that is the only guaranteed time for a given IP
>> address. There is no mandate that the server has to give you the same address
>> after 10 minutes when you ask again. It is valid to just get a different one.
>> And that many home routers try to give you back the same one does not mean
>> that they are required to do so.
>>
>> The nice DHCP servers will remember your Ethernet address and/or identity
>> information and give you back your old IP address. Either with the left over
>> lease time or with a brand new lease time. There is really no need to store
>> this information on disk. If the lease expired the information on disk are
>> stale as well. And since our DHCP implementation is so fast, it makes really
>> no difference.
>>
>> It is safer start out with a brand new DHCP lease instead of having to deal
>> with renewal during boot. At least that way you know the DHCP server is still
>> there and you have a valid IP address. Just re-using a stored IP with a
>> left-over lease is not safe anyway. You never know what changed in the
>> network when you were off.
>
> I think there was some misunderstanding here. I don't want to keep the
> lease across reboots. I don't care about that. I think networkd should
> remember the lease when restarting networkd only and not send a new dhcp
> discover.

Right, I spoke too quickly. What I don't want is to preserve state
between reboots, preserving it between restarts of networkd would
indeed be fine. We already serialize the dhcp leases to /run, so I'd
be happy to take a patch to deserialize these again when networkd
starts.

That said, I'm not sure this will help you much in your case. It would
allow us to explicitly request the current IP address when restarting
networkd, but according to your previous email you already are getting
assigned the correct IP address at first, and then only later does
this change. What is causing your DHCP server to send out a different
IP address later on, I don't know, but it seems unlikely that this is
anything we can fix in the client.

-t
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Changing configurations with networkd

[Michael Olbrich]

On Wed, Jul 23, 2014 at 04:46:26PM +0200, Marcel Holtmann wrote:
> Hi Michael,
> 
> >>> I think the lease should be remembered and reused in this case.
> >> 
> >> Hm, this sounds like a bug somewhere. When the new discover is sent
> >> out it should send the same identifying information to the server, and
> >> hence be given the same lease back again. Wireshark should tell you if
> >> the fault is networkd's or the DHCP server.
> > 
> > I get the same address at first, but after several minutes the DHCP server
> > decides to offer a new address. I should note, that I have a 10 minute
> > lease time for debugging purposes, so that might make the problem more
> > prominent. I'll see if I can figure out what happens here.
> 
> look at your DHCP server and see what lease time it really hands out after 
> reboot.
> 
> However this is between you and your DHCP server. If you configure a lease
> time of 10 minutes, then that is the only guaranteed time for a given IP
> address. There is no mandate that the server has to give you the same address
> after 10 minutes when you ask again. It is valid to just get a different one.
> And that many home routers try to give you back the same one does not mean
> that they are required to do so.
> 
> The nice DHCP servers will remember your Ethernet address and/or identity
> information and give you back your old IP address. Either with the left over
> lease time or with a brand new lease time. There is really no need to store
> this information on disk. If the lease expired the information on disk are
> stale as well. And since our DHCP implementation is so fast, it makes really
> no difference.
> 
> It is safer start out with a brand new DHCP lease instead of having to deal
> with renewal during boot. At least that way you know the DHCP server is still
> there and you have a valid IP address. Just re-using a stored IP with a
> left-over lease is not safe anyway. You never know what changed in the
> network when you were off.

I think there was some misunderstanding here. I don't want to keep the
lease across reboots. I don't care about that. I think networkd should
remember the lease when restarting networkd only and not send a new dhcp
discover.

Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel