Re: [systemd-devel] How to create a systemd service?

[Mantas Mikulėnas]

On Wed, Dec 17, 2014 at 4:34 AM, jenia.ivlev  wrote:
>
> Hello.
>
> I want to start synapse (its a program that allows to run programs more
> easily) at login using systemd. So I created this systemd-service config
> file:
>
> [Unit]
> Description=Syanpse start up
> After=lxdm.service
>
> [Service]
> User=jenia
> ExecStart=/usr/bin/synapse
>
> [Install]
> WantedBy=multi-user.target
>
> I doesnt work neither automatically, nor by calling
> /usr/lib/systemd/system/synapse.service as so:
> systemctl start synapse
>

I see that Synapse is an X11 program, gtk-based. The system service
manager, whether it was systemd or another init, is not suitable for this
because it has no knowledge about the X11 sessions that might be active.

(Indeed, "After=lxdm.service" won't actually make it start _at login_, but
at the time the welcome screen shows up.)



Remember that by design there can be zero or several people running their
own X11 servers at once; programs therefore need to know environment
variables like $DISPLAY (and several others) to choose the right one.
That's why you get this:


> Dec 16 21:23:11 station1 synapse[8545]: [02:23:11.040620 Gtk-Warning]
> cannot open display:
>

Setting these variables statically in your .service would be a poor idea
since they can change (some of them _do_ change every time lxdm starts),
not to mention being exactly the kind of ugly hack that systemd tries to
avoid.

(And while systemd _is_ trying to eventually reach the point where simply
setting User= should be enough to discover all such information, it still
wouldn't help you, because your service still starts together with lxdm,
_before_ you actually log in.)



For now, it will be easiest to start such services from your desktop
environment, as it already runs inside your graphical login and therefore
knows all the necessary settings.

Whether you use GNOME or Enlightenment or LXDE or a custom-built
environment on top of a tiny tiling WM, they all have ways to autostart
programs. Most of them support the XDG Autostart

specification. Put this in ~/.config/autostart/synapse.desktop:

[Desktop Entry]
Type=Application
Name=Synapse
Exec=/usr/bin/synapse

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

Re: [systemd-devel] [PATCH] nspawn: fix invocation of the raw clone() system call on s390 and cris

[Zbigniew Jędrzejewski-Szmek]

On Tue, Dec 16, 2014 at 06:06:41PM +0100, Ken Werner wrote:
> From: Ken Werner 
> 
> Since the order of the first and second arguments of the raw clone() system
> call is reversed on s390 and cris it needs to be invoked differently.
Applied.

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

[systemd-devel] How to create a systemd service?

[jenia.ivlev]

Hello. 

I want to start synapse (its a program that allows to run programs more
easily) at login using systemd. So I created this systemd-service config file:

[Unit]
Description=Syanpse start up
After=lxdm.service

[Service]
User=jenia
ExecStart=/usr/bin/synapse

[Install]
WantedBy=multi-user.target

I doesnt work neither automatically, nor by calling
/usr/lib/systemd/system/synapse.service as so:
systemctl start synapse

It tells me:

● synapse.service - Syanpse start up
   Loaded: loaded (/usr/lib/systemd/system/synapse.service; enabled)
   Active: failed (Result: exit-code) since Tue 2014-12-16 21:23:11 EST; 
8min ago
  Process: 8545 ExecStart=/usr/bin/synapse (code=exited, status=1/FAILURE)
 Main PID: 8545 (code=exited, status=1/FAILURE)

Dec 16 21:23:11 station1 systemd[1]: Started Syanpse start up.
Dec 16 21:23:11 station1 synapse[8545]: [02:23:11.039206 Info] Starting 
up...
Dec 16 21:23:11 station1 synapse[8545]: [02:23:11.040620 Gtk-Warning] 
cannot open display:
Dec 16 21:23:11 station1 systemd[1]: synapse.service: main process exited, 
code=exited, status=1/FAILURE
Dec 16 21:23:11 station1 systemd[1]: Unit synapse.service entered failed 
state.
Dec 16 21:23:11 station1 systemd[1]: synapse.service failed.

How do I make this work, can someone please tell me?

Thanks in advance for your help and kind concern.




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

Re: [systemd-devel] [PATCH] path: follow symbolic link for parent path

[Zbigniew Jędrzejewski-Szmek]

On Tue, Dec 16, 2014 at 09:58:39PM +0100, Umut Tezduyar Lindskog wrote:
> ---
>  src/shared/path-util.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/shared/path-util.c b/src/shared/path-util.c
> index dcc8321..304281f 100644
> --- a/src/shared/path-util.c
> +++ b/src/shared/path-util.c
> @@ -518,7 +518,7 @@ fallback:
>  if (r < 0)
>  return r;
>  
> -r = lstat(parent, &b);
> +r = stat(parent, &b);
>  if (r < 0)
>  return -errno;
Applied.

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

Re: [systemd-devel] serialization bug, swap bug, etc.

[Filipe Brandenburger]

On Wed, Dec 10, 2014 at 4:11 AM, Lennart Poettering
 wrote:
> In fact, I think we should drop the
> libcap dependency altogether and just do the two syscalls it offers to
> us natively in systemd code. Neither is libcap a particularly nice
> library, nor is the stuff it does particularly complex, hence we can
> as well wrap the two calls we need in our code.

I started looking at this and I just sent a patch set to remove the
include of  where it was not really in use.

Regarding the valid uses of libcap, it looks like the non-trivial part
is cap_to_text/cap_from_text which we would have to reimplement and
possibly keep them in sync with libcap.

libcap also tries to support kernels which only support 32-bit
capabilities. If we replace that code, should we make an assumption of
64-bit capabilities and just use a uint64_t to represent the bits?

Let me know if you think this is something worth doing and I can
contribute an implementation.

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

Re: [systemd-devel] [dm-devel] multipath breaks with recent udev/systemd

[Benjamin Marzinski]

On Tue, Dec 16, 2014 at 04:10:44PM -0600, Benjamin Marzinski wrote:
> On Mon, Dec 15, 2014 at 10:31:44AM +0100, Hannes Reinecke wrote:
> > Hi all,
> > 
> > in commit 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
> > (udev: serialize/synchronize block device event handling with file
> > locks) udev started using flock() on the device node, supposedly to
> > synchronize with an ominous 'block event handling'.
> > 
> > The code looks like this:
> > 
> >   if (d) {
> > fd_lock = open(udev_device_get_devnode(d),
> > O_RDONLY|O_CLOEXEC|O_NOFOLLOW|O_NONBLOCK);
> > if (fd_lock >= 0 && flock(fd_lock,
> > LOCK_SH|LOCK_NB) < 0) {
> >  log_debug("Unable to flock(%s),
> > skipping event handling: %m", udev_device_get_devnode(d));
> >  err = -EWOULDBLOCK;
> >  goto skip;
> >}
> >}
> > 
> > However, multipath since several years is using a similar construct
> > to lock all devices belonging to a multipath device table before
> > creating a mulitpath dm-device:
> > 
> > vector_foreach_slot (mpp->pg, pgp, i) {
> > if (!pgp->paths)
> > continue;
> > vector_foreach_slot(pgp->paths, pp, j) {
> > if (lock && flock(pp->fd, LOCK_SH | LOCK_NB) &&
> > errno == EWOULDBLOCK)
> > goto fail;
> > else if (!lock)
> > flock(pp->fd, LOCK_UN);
> > }
> > }
> > 
> > So during bootup it's anyone's guess who's first, multipath or udev.
> > And depending on the timing either multipath will fail to setup
> > the device-mapper device or udev will simply ignore the device.
> > Neither of those is a good, but the first is an absolute killer for
> > modern systems which _rely_ on udev to configure devices.
> > 
> > So how it this supposed to work?
> > Why does udev ignore the entire event if it can't get the lock?
> > Shouldn't it rather be retried?
> > What is the supposed recovery here?
> 
> Hannes, are you against the idea that Alexander mentioned in his first
> email, of just locking a file in /var/lock?  Multipathd doesn't create
> devices in parallel. Multipath doesn't create files in parallel.  We are
> explicitly trying to avoid multipath and multipathd creating files at
> the same time. So, we should only need a single file to lock, and
> /run/lock should always be there.

O.k. So if we want to keep our current nonblocking behavior, we'll need
more lockfiles, either one per path or one per wwid.  This still seems
like a reasonable idea, if there is a good reason for systemd doing what
it's doing.

-Ben

> 
> -Ben
> 
> > 
> > Cheers,
> > 
> > Hannes
> > -- 
> > Dr. Hannes ReineckezSeries & Storage
> > h...@suse.de   +49 911 74053 688
> > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> > GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
> > HRB 21284 (AG Nürnberg)
> 
> --
> dm-devel mailing list
> dm-de...@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] multipath breaks with recent udev/systemd

[Benjamin Marzinski]

On Mon, Dec 15, 2014 at 10:31:44AM +0100, Hannes Reinecke wrote:
> Hi all,
> 
> in commit 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
> (udev: serialize/synchronize block device event handling with file
> locks) udev started using flock() on the device node, supposedly to
> synchronize with an ominous 'block event handling'.
> 
> The code looks like this:
> 
>   if (d) {
> fd_lock = open(udev_device_get_devnode(d),
> O_RDONLY|O_CLOEXEC|O_NOFOLLOW|O_NONBLOCK);
> if (fd_lock >= 0 && flock(fd_lock,
> LOCK_SH|LOCK_NB) < 0) {
>  log_debug("Unable to flock(%s),
> skipping event handling: %m", udev_device_get_devnode(d));
>  err = -EWOULDBLOCK;
>  goto skip;
>}
>}
> 
> However, multipath since several years is using a similar construct
> to lock all devices belonging to a multipath device table before
> creating a mulitpath dm-device:
> 
>   vector_foreach_slot (mpp->pg, pgp, i) {
>   if (!pgp->paths)
>   continue;
>   vector_foreach_slot(pgp->paths, pp, j) {
>   if (lock && flock(pp->fd, LOCK_SH | LOCK_NB) &&
>   errno == EWOULDBLOCK)
>   goto fail;
>   else if (!lock)
>   flock(pp->fd, LOCK_UN);
>   }
>   }
> 
> So during bootup it's anyone's guess who's first, multipath or udev.
> And depending on the timing either multipath will fail to setup
> the device-mapper device or udev will simply ignore the device.
> Neither of those is a good, but the first is an absolute killer for
> modern systems which _rely_ on udev to configure devices.
> 
> So how it this supposed to work?
> Why does udev ignore the entire event if it can't get the lock?
> Shouldn't it rather be retried?
> What is the supposed recovery here?

Hannes, are you against the idea that Alexander mentioned in his first
email, of just locking a file in /var/lock?  Multipathd doesn't create
devices in parallel. Multipath doesn't create files in parallel.  We are
explicitly trying to avoid multipath and multipathd creating files at
the same time. So, we should only need a single file to lock, and
/run/lock should always be there.

-Ben

> 
> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke  zSeries & Storage
> h...@suse.de +49 911 74053 688
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
> HRB 21284 (AG Nürnberg)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] path: follow symbolic link for parent path

[Umut Tezduyar Lindskog]

---
 src/shared/path-util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/shared/path-util.c b/src/shared/path-util.c
index dcc8321..304281f 100644
--- a/src/shared/path-util.c
+++ b/src/shared/path-util.c
@@ -518,7 +518,7 @@ fallback:
 if (r < 0)
 return r;
 
-r = lstat(parent, &b);
+r = stat(parent, &b);
 if (r < 0)
 return -errno;
 
-- 
2.1.1

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

Re: [systemd-devel] Improving module loading

[Jóhann B. Guðmundsson]

On 12/16/2014 03:54 PM, Umut Tezduyar Lindskog wrote:

Hi,

Is there a reason why systemd-modules-load is loading modules
sequentially? Few things can happen simultaneously like resolving the
symbols etc. Seems like modules_mutex is common on module loads which
gets locked up on few occasions throughout the execution of
sys_init_module.

The other thought is, what is the preferred way of loading modules
when they are needed. Do they have to be loaded on ExecStartPre= or as
a separate service which has ExecStart that uses kmod to load them?
Wouldn't it be useful to have something like ExecStartModule=?



Kernel modules should never be loaded from type systemd units

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

Re: [systemd-devel] [PATCH] bus-proxy: cloning smack label

[Karol Lewandowski]

On 2014-12-10 22:37, Lennart Poettering wrote:
> On Tue, 09.12.14 18:26, Lennart Poettering (lenn...@poettering.net) wrote:
> 
> Przemyslaw,
> 
>>> +++ b/units/u...@.service.m4.in
>>> @@ -0,0 +1,23 @@
>>> +#  This file is part of systemd.
>>> +#
>>> +#  systemd is free software; you can redistribute it and/or modify it
>>> +#  under the terms of the GNU Lesser General Public License as published by
>>> +#  the Free Software Foundation; either version 2.1 of the License, or
>>> +#  (at your option) any later version.
>>> +
>>> +[Unit]
>>> +Description=User Manager for UID %i
>>> +After=systemd-user-sessions.service
>>> +
>>> +[Service]
>>> +User=%i
>>> +PAMName=systemd-user
>>> +Type=notify
>>> +ExecStart=-@rootlibexecdir@/systemd --user
>>> +Slice=user-%i.slice
>>> +KillMode=mixed
>>> +Delegate=yes
>>> +m4_ifdef(`HAVE_SMACK',
>>> +Capabilities=cap_mac_admin=i
>>> +SecureBits=keep-caps
>>> +)
> 
> I have reverted the last bit above again, since it broke bootups in
> nspawn machines. I figure the CAP_MAC_ADMIN capability is missing from
> the bounding set in an nspawn, and that breaks the caps logic here.
> 
> We should find another solution for this. I wanted to get 218 out of
> the door, hence I reverted this bit for now, but we really should fine
> a longer term solution for this.
> 
> I build systemd with SMACK on, but turned off in the kernel. 
> 
> Any suggestions what we can do here?

ConditionSecurity=smack instead of HAVE_SMACK would work, but it would
also require separate unit for non-smack case, which is crap.  No easy
solutions come to my mind right now, unfortunately...

Cheers,
-- 
Karol Lewandowski, Samsung R&D Institute Poland
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] nspawn: fix invocation of the raw clone() system call on s390 and cris

[Ken Werner]

From: Ken Werner 

Since the order of the first and second arguments of the raw clone() system
call is reversed on s390 and cris it needs to be invoked differently.

Signed-off-by: Ken Werner 
---
 src/nspawn/nspawn.c  |6 +++---
 src/shared/missing.h |   10 ++
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 9ca53cd..a13c1fc 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -3133,9 +3133,9 @@ int main(int argc, char *argv[]) {
 goto finish;
 }
 
-pid = syscall(__NR_clone, SIGCHLD|CLONE_NEWNS|
-  (arg_share_system ? 0 : 
CLONE_NEWIPC|CLONE_NEWPID|CLONE_NEWUTS)|
-  (arg_private_network ? CLONE_NEWNET 
: 0), NULL);
+pid = raw_clone(SIGCHLD|CLONE_NEWNS|
+(arg_share_system ? 0 : 
CLONE_NEWIPC|CLONE_NEWPID|CLONE_NEWUTS)|
+(arg_private_network ? CLONE_NEWNET : 0), 
NULL);
 if (pid < 0) {
 if (errno == EINVAL)
 r = log_error_errno(errno, "clone() failed, do 
you have namespace support enabled in your kernel? (You need UTS, IPC, PID and 
NET namespacing built in): %m");
diff --git a/src/shared/missing.h b/src/shared/missing.h
index c547479..bea1254 100644
--- a/src/shared/missing.h
+++ b/src/shared/missing.h
@@ -635,3 +635,13 @@ static inline int setns(int fd, int nstype) {
 #ifndef CAP_AUDIT_READ
 #define CAP_AUDIT_READ 37
 #endif
+
+static inline long raw_clone(unsigned long flags, void *child_stack) {
+#if defined(__s390__) || defined(__CRIS__)
+/* On s390 and cris the order of the first and second arguments
+ * of the raw clone() system call is reversed. */
+return syscall(__NR_clone, child_stack, flags);
+#else
+return syscall(__NR_clone, flags, child_stack);
+#endif
+}
-- 
1.7.1

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

Re: [systemd-devel] [PATCH v2] Add FDB support

[Tom Gundersen]

On Tue, Dec 16, 2014 at 5:15 PM, Rauta, Alin  wrote:
> Sorry,  "between systemd restarts".

Right. That's what I thought. In that case I would not worry about it
for now, as explained previously, and rather handle it together with
the flushing of addresses and routes when we get to that.

Cheers,

Tom

> -Original Message-
> From: Tom Gundersen [mailto:t...@jklm.no]
> Sent: Tuesday, December 16, 2014 3:56 PM
> To: Rauta, Alin
> Cc: Lennart Poettering; systemd Mailing List; Kinsella, Ray
> Subject: Re: [systemd-devel] [PATCH v2] Add FDB support
>
> On Tue, Dec 16, 2014 at 4:28 PM, Rauta, Alin  wrote:
>> Regarding the flushing of entries that's done because we don't want to have 
>> dangling configuration between system restarts,
>
> You mean these settings are remembered by the hardware between reboots?
>
> Cheers,
>
> Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database

[Dan Williams]

On Tue, 2014-12-16 at 08:45 +0100, David Herrmann wrote:
> Hi
> 
> On Mon, Dec 15, 2014 at 9:20 PM, Dan Williams  wrote:
> > On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote:
> >> systemd tries to launch logind service which now waits for services it
> >> is ordered After and eventually times out.
> >
> > NM patch filed for review by NM dev team:
> >
> > https://bugzilla.gnome.org/show_bug.cgi?id=741572
> 
> Thanks a lot!

Update: the patch has been reviewed and pushed to NM git master (will
eventually be 1.2), nm-1-0, and nm-0-9-10 branches.

Dan

> > Also, I don't think logind should fail if there is no network; no reason
> > for it to crash and burn just because everything isn't quite ready when
> > it starts.  I presume it's got capability to deal with sporadic network
> > outages, and that's not really different than waiting for networking to
> > show up soon after it starts.  But not my department...
> 
> When a user loggs in, we resolve the name to UID. As the initial
> logind binary was only used for login management, it was reasonable to
> avoid starting up before the nss-user-lookup is initialized. Now that
> systemd-logind provides other independent APIs, it might be ok to drop
> that requirement again.
> If the nss user lookup is not ready at the time someone logs in, we
> will print a warning and skip tracking that session. Sounds fine to
> me, but Lennart might have more comments.
> 
> Thanks
> David


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

Re: [systemd-devel] [PATCH] nspawn: fix invocation of the raw clone() system call on s390 and cris

[Ken Werner]

On 12/15/2014 06:27 PM, Lennart Poettering wrote:

On Mon, 15.12.14 08:01, Ken Werner (k...@linux.vnet.ibm.com) wrote:


From: Ken Werner 

Since the order of the first and second arguments of the raw clone()
system call is reversed on s390 and cris it needs to be invoked differently.

Signed-off-by: Ken Werner 


Hmm, I'd prefer if we could move the definition of this syscall
wrapper into missing.h, and do the per-arch magic there, like we do
for all the other syscalls missing from glibc. Maybe call the function
"raw_clone()" there or so.


Alright, I'll create and post an updated patch.


Alternatively we could move to the glibc-provided wrapper, but I think
it's nastier to use, since it requires a stack parameter to be
specified.


@@ -3133,9 +3133,17 @@ int main(int argc, char *argv[]) {
  goto finish;
  }

+#if defined(__s390__) || defined(__CRIS)
+/* On s390 and cris the order of the first and second arguments
+ * of the raw clone() system call is reversed. */
+pid = syscall(__NR_clone, NULL, SIGCHLD|CLONE_NEWNS|
+  (arg_share_system ? 0 : 
CLONE_NEWIPC|CLONE_NEWPID|CLONE_NEWUTS)|
+  (arg_private_network ? CLONE_NEWNET 
: 0));
+#else
  pid = syscall(__NR_clone, SIGCHLD|CLONE_NEWNS|
(arg_share_system ? 0 : 
CLONE_NEWIPC|CLONE_NEWPID|CLONE_NEWUTS)|
(arg_private_network ? CLONE_NEWNET 
: 0), NULL);
+#endif
  if (pid < 0) {
  if (errno == EINVAL)
  r = log_error_errno(errno, "clone() failed, do you 
have namespace support enabled in your kernel? (You need UTS, IPC, PID and NET 
namespacing built in): %m");
--
1.7.1

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



Lennart


Regards,
Ken

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

Re: [systemd-devel] [PATCH v2] Add FDB support

[Rauta, Alin]

Sorry,  "between systemd restarts".
/Alin

-Original Message-
From: Tom Gundersen [mailto:t...@jklm.no] 
Sent: Tuesday, December 16, 2014 3:56 PM
To: Rauta, Alin
Cc: Lennart Poettering; systemd Mailing List; Kinsella, Ray
Subject: Re: [systemd-devel] [PATCH v2] Add FDB support

On Tue, Dec 16, 2014 at 4:28 PM, Rauta, Alin  wrote:
> Regarding the flushing of entries that's done because we don't want to have 
> dangling configuration between system restarts,

You mean these settings are remembered by the hardware between reboots?

Cheers,

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

Re: [systemd-devel] Improving module loading

[Umut Tezduyar Lindskog]

On Tue, Dec 16, 2014 at 4:59 PM, Tom Gundersen  wrote:
> On Tue, Dec 16, 2014 at 4:54 PM, Umut Tezduyar Lindskog
>  wrote:
>> The other thought is, what is the preferred way of loading modules
>> when they are needed.
>
> Rely on kernel autoloading. Not all modules support that yet, but most
> do. What do you have in mind?

We have some modules that we don't need them to be loaded so early. We
much prefer them to be loaded when they are needed. For example we
don't need to load the SD driver module until the service that uses SD
driver is starting. With this idea in mind I started some
investigation. Then I realized that our CPU utilization is not that
high during module loading and I blame it to the sequential loading of
modules. I am thinking this can be improved on systemd-modules-load
side.

>
>> Do they have to be loaded on ExecStartPre= or as
>> a separate service which has ExecStart that uses kmod to load them?
>> Wouldn't it be useful to have something like ExecStartModule=?
>
> I'd much rather we improve the autoloading support...

My understanding is autoloading support is loading a module if the
hardware is available. What I am after is though loading the module
when they are needed.

Umut

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

Re: [systemd-devel] Improving module loading

[Tom Gundersen]

On Tue, Dec 16, 2014 at 4:54 PM, Umut Tezduyar Lindskog
 wrote:
> The other thought is, what is the preferred way of loading modules
> when they are needed.

Rely on kernel autoloading. Not all modules support that yet, but most
do. What do you have in mind?

> Do they have to be loaded on ExecStartPre= or as
> a separate service which has ExecStart that uses kmod to load them?
> Wouldn't it be useful to have something like ExecStartModule=?

I'd much rather we improve the autoloading support...

Cheers,

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

Re: [systemd-devel] [PATCH v2] Add FDB support

[Tom Gundersen]

On Tue, Dec 16, 2014 at 4:28 PM, Rauta, Alin  wrote:
> Regarding the flushing of entries that's done because we don't want to have 
> dangling configuration between system restarts,

You mean these settings are remembered by the hardware between reboots?

Cheers,

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

[systemd-devel] Improving module loading

[Umut Tezduyar Lindskog]

Hi,

Is there a reason why systemd-modules-load is loading modules
sequentially? Few things can happen simultaneously like resolving the
symbols etc. Seems like modules_mutex is common on module loads which
gets locked up on few occasions throughout the execution of
sys_init_module.

The other thought is, what is the preferred way of loading modules
when they are needed. Do they have to be loaded on ExecStartPre= or as
a separate service which has ExecStart that uses kmod to load them?
Wouldn't it be useful to have something like ExecStartModule=?

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

Re: [systemd-devel] [PATCH v2] Add FDB support

[Rauta, Alin]

Hi Tom,

Thanks for your feedback. I will change "VLAN" to "VLANId" in the next patch. 
Regarding the flushing of entries that's done because we don't want to have 
dangling configuration between system restarts, but currently the discussion is 
ongoing internally and it may take some time. 

Best Regards,
Alin

-Original Message-
From: Tom Gundersen [mailto:t...@jklm.no] 
Sent: Monday, December 15, 2014 5:49 PM
To: Rauta, Alin
Cc: Lennart Poettering; systemd Mailing List; Kinsella, Ray
Subject: Re: [systemd-devel] [PATCH v2] Add FDB support

Hi Alin,

Thanks for the patch!

Overall it looks excellent, my only concern is with the clearing of FDB 
entries. Is there any reason to treat this differently than how we currently 
treat routes and addresses?

The current logic is that we don't support run-time reconfiguration (we only 
apply our (static) config once when the interfaces appear, and that's it). If 
there is some config there already we assume that it is intentional and leave 
it alone (i.e., if someone else have set addresses or routes we don't remove 
them, we just add new ones). In the future we plan to get a dbus API where 
networkd can be reconfigured at run-time (i.e., change which .network file is 
applied to a link), and then it definitely would make sense to flush routes and 
addresses when removing the .network from the link, but currently we don't do 
that at all.

If people want to reconfigure stuff now, they can of course just restart 
networkd, but then they should also manually flush the settings from the 
kernel, and this (changing the config, restarting the daemon and flushing) is 
more of a hack for testing than something we support.

So the question I have is: can we treat FDB entries the same as routes and 
addresses and simply leave them alone rather than flushing them, and then only 
add the flushing logic once we start supporting reconfiguration? If not, can 
you explain a bit more what the typical usecase is where flushing is desirable?

As to the naming, I like the suggestion made above to call it "VLANId"
rather than "VLAN".

Cheers,

Tom

On Mon, Dec 15, 2014 at 11:20 AM, Alin Rauta  wrote:
> Hi,
>
> Based on your feedback, I've created a new patch for adding the FDB support.
> networkd takes ownership of the FDB table.
>
> Configuration example:
>
>> cat /etc/systemd/network/em1.network
>
> [Match]
> Name=em1
>
> [Network]
> DHCP=v4
>
> [BridgeFDB]
> MACAddress=04:44:12:34:56:70
> VLAN=2
>
> [BridgeFDB]
> MACAddress=04:44:12:34:56:69
> VLAN=3
>
> Let me know what you think.
>
> Thanks,
> Alin
>
> Alin Rauta (1):
>   Add FDB support
>
>  Makefile.am  |   1 +
>  man/systemd.network.xml  |  22 ++
>  src/libsystemd/sd-rtnl/rtnl-message.c|  56 -
>  src/libsystemd/sd-rtnl/rtnl-types.c  |  15 +-
>  src/network/networkd-fdb.c   | 357 
> +++
>  src/network/networkd-link.c  |  25 +++
>  src/network/networkd-network-gperf.gperf |   2 +
>  src/network/networkd-network.c   |  13 +-
>  src/network/networkd.h   |  30 +++
>  src/systemd/sd-rtnl.h|   4 +
>  10 files changed, 514 insertions(+), 11 deletions(-)  create mode 
> 100644 src/network/networkd-fdb.c
>
> --
> 1.9.3
>
> ___
> 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] Build error with 218 - undefined reference to `__start_BUS_ERROR_MAP'

[Umut Tezduyar Lindskog]

For the reference, -flto option was preventing static linker from
making the assignments. Could be very well something specific to our
toolchain.

On Fri, Dec 12, 2014 at 11:50 PM, Umut Tezduyar Lindskog
 wrote:
> On Fri, Dec 12, 2014 at 4:46 PM, Lennart Poettering
>  wrote:
>> On Fri, 12.12.14 10:10, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
>>
>>> >
>>> > https://sourceware.org/bugzilla/show_bug.cgi?id=11133
>>> >
>>> > But that's 4y old... Or is your toolchain that old?
>>>
>>> Shouldn't be:
>>>
>>> mipsisa32r2el-axis-linux-gnu-gcc --version
>>> mipsisa32r2el-axis-linux-gnu-gcc (GCC 4.7.2 Axis release R24/1.24)
>>> 4.7.2 20120820 (prerelease) [gcc-4_7-branch revision 190527]
>>
>> That's the gcc version. And what binutils version is this?
>
> mipsisa32r2el-axis-linux-gnu-ld --version
> GNU ld (GNU Binutils) 2.24.51.20131126
> Copyright 2013 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later version.
> This program has absolutely no warranty.
>
> I will double check things with our compiler tools group.
>
>>
>> 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] systemd boot issue

[P J P]

> On Tuesday, 16 December 2014 10:41 AM, P J P wrote:

>> and now after 6-7 hours suddenly I see the login prompt with kernel-3.18.0. 
>> I have hit 
>> # shutdown -r now
>> and boot-up has stalled at the same spot again. Let's see...
> 
> I've restarted it with
>- systemd.log_level=debug systemd.log_target=kmsg enforcing=0.


It is reproducible. With the above parameters the VM hangs for long at - 
Starting Switch Root... -
But eventually continues to boot and show the login prompt after > 3 hours.

  -> http://fpaste.org/160132/

[13494.227608] systemd[1]: Startup finished in 2.039s (kernel) + 3.288s 
(initrd) + 3h 44min 48.899s (userspace) = 3h 44min 54.227s.


systemd(1) is is taking 3:44 hours it seems. Another glitch is network.service 
fails to come up. :(

  - Is there a way to see why/where is it spending 3 hours?
  - Could enforcing=0 be a clue to maybe something is up with SELinux?

Any suggestions would be helpful.
---
Regards
   -P J P
http://feedmug.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fedora 21: Cannot scan to EPSON WF-2540

[Jóhann B. Guðmundsson]

Hi

It's much simpler that you simply add a neat comment in that bug report 
and or sane upstream that you tested what Zbyszek proposed and it 
worked, rather than sending mail to 4 individuals and two mailinglist 
and at the same time leave out that information from the bug report 
where this all started.


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