[systemd-devel] Fedora on systemd-nspawn container - ML best practice

[arnaud gaboury]

I started running Fedora server on a systemd-nspawn container.

I am wondering what is the best practice when an issue occurs:
- send to Fedora user ML
- send to systemd-devel ML
- send both with CC

I am afraid that when sending to only one list I will be told to ask
the other one, thus wasting time between the two lists. On the other
hand, CC to both lists can be viewed as spam.

From a user point of view, best would be to post to both lists as long
as the issue can come from systemd-nspawn functionality or Fedora.

use case: after install, boot, upgrade Fedora container, network is
down in container (when it used to work to install some new packages).

Thank you for advice about ML posting.

-- 

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

[systemd-devel] DefaultDependencies of [Unit]

[樊超]

I want to let my service run when shutdown,and it needn't close by
systemd,so can i set the DefaultDependencies of [Unit] to "no"?
I don't understand the meaning of DefaultDependencies.
It's [Unit] like this:
After=network.target network-online.target remote-fs.target
And I want to know if it matters when start the pc if I set
DefaultDependencies of [Unit] to "no"
Thanks.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] udev: hwdb: Add trackpoint sensitivity settings for Lenovo X240 and 540p

[Hans de Goede]

Like the T440s these need the sensitity to be set significantly higher
then the default of 128 for the trackpoint to be usable. Like with the
T440s 200 seems to be a good value to get a reasonable but not too high
sensitivity.

Signed-off-by: Hans de Goede 
---
 hwdb/70-pointingstick.hwdb | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb
index 8d210f9..f18b6d4 100644
--- a/hwdb/70-pointingstick.hwdb
+++ b/hwdb/70-pointingstick.hwdb
@@ -93,7 +93,17 @@ evdev:name:TPPS/2 IBM 
TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX20?
   POINTINGSTICK_SENSITIVITY=200
   POINTINGSTICK_CONST_ACCEL=1.25
 
+# Lenovo Thinkpad X240
+evdev:name:TPPS/2 IBM 
TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX240:*
+  POINTINGSTICK_SENSITIVITY=200
+  POINTINGSTICK_CONST_ACCEL=1.0
+
 # Lenovo Thinkpad T440s
 evdev:name:TPPS/2 IBM 
TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadT440s:*
   POINTINGSTICK_SENSITIVITY=200
   POINTINGSTICK_CONST_ACCEL=1.0
+
+# Lenovo Thinkpad T540p
+evdev:name:TPPS/2 IBM 
TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadT540p:*
+  POINTINGSTICK_SENSITIVITY=200
+  POINTINGSTICK_CONST_ACCEL=1.0
-- 
2.3.6

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

Re: [systemd-devel] [systemd-nspawn] nginx: [emerg] open() "/dev/stderr" failed (6: No such device or address)

[Lennart Poettering]

On Tue, 28.04.15 07:05, Peter Paule (systemd-de...@fedux.org) wrote:

> > Hmm, but that already lists a native config keyword for "stderr"?
> > 
> 
> Yes, I saw that too late. I copied the default configuration of the Arch Linux
> nginx package and used that.

So, does it work if you use the config keyword "stderr" there?

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] DefaultDependencies of [Unit]

[Lennart Poettering]

On Tue, 28.04.15 16:19, 樊超 (fcvi...@gmail.com) wrote:

> I want to let my service run when shutdown,and it needn't close by
> systemd,so can i set the DefaultDependencies of [Unit] to "no"?
> I don't understand the meaning of DefaultDependencies.
> It's [Unit] like this:
> After=network.target network-online.target remote-fs.target
> And I want to know if it matters when start the pc if I set
> DefaultDependencies of [Unit] to "no"

Sure it matters. If DefaultDependencies=yes you get ordered after
basic.target and are shut down before shutdown.target is
reached. If you set DefaultDependencies=no you are started really
really early on (unless you explicitly order yourself after
basic.target). That means you'd have to make sure your service is
written in a way it can handle being run that early and doesn't assume
directories like /var are already mounted, or specific other services
already running. Similar, during shutdown if you continue to access
/var this late you will keep the mount for it busy, and accessing
other services might fail earlier than expected.

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] Fedora on systemd-nspawn container - ML best practice

[Lennart Poettering]

On Tue, 28.04.15 09:31, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:

> I started running Fedora server on a systemd-nspawn container.
> 
> I am wondering what is the best practice when an issue occurs:
> - send to Fedora user ML
> - send to systemd-devel ML
> - send both with CC
> 
> I am afraid that when sending to only one list I will be told to ask
> the other one, thus wasting time between the two lists. On the other
> hand, CC to both lists can be viewed as spam.
> 
> From a user point of view, best would be to post to both lists as long
> as the issue can come from systemd-nspawn functionality or Fedora.
> 
> use case: after install, boot, upgrade Fedora container, network is
> down in container (when it used to work to install some new packages).
> 
> Thank you for advice about ML posting.

Cross-posting is not particularly popular, so I'd avoid it.

If it's nspawn related it's probably best to keep it on the systemd
ML.

Consider using using systemd-networkd in the container and on the
host. If so the network should just work between them.

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] users and per user limits (tmpfs)

[Lennart Poettering]

On Tue, 28.04.15 00:55, Michał Zegan (webczat_...@poczta.onet.pl) wrote:

> Hello.
> 
> I have discovered how to add resource limits for the user, like how
> much memory the user can use, or how much cpu time.
> Here is the problem: /tmp seems a way for the user to circumvent this
> restriction. Is there a way to protect it too?

Nope. There have been discussions for adding quota to tmpfs, but this
lead nowhere.

You can disable tmpfs-on-/tmp, and run it on xfs or ext4 instead and
use classic per-user quota though.

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] man systemd.network question

[Lennart Poettering]

On Mon, 27.04.15 23:35, Kai Krakow (hurikha...@gmail.com) wrote:

> Hello!
> 
> The man page reads:
> 
> [MATCH] SECTION OPTIONS
>The network file contains a "[Match]" section, which determines if a
>given network file may be applied to a given device; and a
>"[Network]" section specifying how the device should be configured.
>The first (in lexical order) of the network files that matches a
>given device is applied.
> 
> What does this exactly mean? Will it process further files or stop 
> processing files after a match?

It stops
> 
> Usually, my experience with unix says, that when files are processed in 
> lexical order, settings from earlier files are overridden by settings from 
> later files - like e.g. in /etc/env.d
> 
> In that sense, it can only mean that the processing stops at the first 
> matching files. Otherwise the order of overriding would be reversed from 
> expectations.
> 
> I think this should be made more clear in the man page, like by "The 
> processing of files stops at the first match." This would follow example of 
> how other projects document behaviour.

I added such a note now. 

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] users and per user limits (tmpfs)

[Michał Piotrowski]

Hi,

2015-04-28 11:39 GMT+02:00 Lennart Poettering :

> On Tue, 28.04.15 00:55, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
>
> > Hello.
> >
> > I have discovered how to add resource limits for the user, like how
> > much memory the user can use, or how much cpu time.
> > Here is the problem: /tmp seems a way for the user to circumvent this
> > restriction. Is there a way to protect it too?
>
> Nope. There have been discussions for adding quota to tmpfs, but this
> lead nowhere.
>

https://bugzilla.redhat.com/show_bug.cgi?id=693253


>
> You can disable tmpfs-on-/tmp, and run it on xfs or ext4 instead and
> use classic per-user quota though.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>



-- 
Best regards,
Michal

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

Re: [systemd-devel] Fedora on systemd-nspawn container - ML best practice

[arnaud gaboury]

 On Tue, Apr 28, 2015, 11:38 AM Lennart Poettering 
wrote:

On Tue, 28.04.15 09:31, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:

> I started running Fedora server on a systemd-nspawn container.
>
> I am wondering what is the best practice when an issue occurs:
> - send to Fedora user ML
> - send to systemd-devel ML
> - send both with CC
>
> I am afraid that when sending to only one list I will be told to ask
> the other one, thus wasting time between the two lists. On the other
> hand, CC to both lists can be viewed as spam.
>
> From a user point of view, best would be to post to both lists as long
> as the issue can come from systemd-nspawn functionality or Fedora.
>
> use case: after install, boot, upgrade Fedora container, network is
> down in container (when it used to work to install some new packages).
>
> Thank you for advice about ML posting.

Cross-posting is not particularly popular, so I'd avoid it.

 I know.

If it's nspawn related it's probably best to keep it on the systemd
ML.

Consider using using systemd-networkd in the container and on the
host. If so the network should just work between them.

 I will as systemd- networkd already manage my network on the host. Btw, as
fedora will act as a server, i will need a fix ip, get rid of ebtables and
firewalld in container (kernel is built with apparmor and grsec) etc etc.
Lot of work

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] users and per user limits (tmpfs)

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

(sorry, I haven't sent a reply to the list)
What about namespacing and mounting tmpfs per user? You can specify a
filesystem size when mounting tmpfs can't you?

W dniu 2015-04-28 o 11:48, Michał Piotrowski pisze:
> Hi,
> 
> 2015-04-28 11:39 GMT+02:00 Lennart Poettering  >:
> 
> On Tue, 28.04.15 00:55, Michał Zegan (webczat_...@poczta.onet.pl 
> ) wrote:
> 
>> Hello.
>> 
>> I have discovered how to add resource limits for the user, like 
>> how much memory the user can use, or how much cpu time. Here is 
>> the problem: /tmp seems a way for the user to circumvent this 
>> restriction. Is there a way to protect it too?
> 
> Nope. There have been discussions for adding quota to tmpfs, but 
> this lead nowhere.
> 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=693253
> 
> 
> 
> You can disable tmpfs-on-/tmp, and run it on xfs or ext4 instead 
> and use classic per-user quota though.
> 
> Lennart
> 
> -- Lennart Poettering, Red Hat 
> ___ systemd-devel 
> mailing list systemd-devel@lists.freedesktop.org 
>  
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
> 
> 
> 
> -- Best regards, Michal
> 
> http://eventhorizon.pl/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVP1rcAAoJEHb1CzgxXKwY3cUP/1QD2c/8xh7vck1hbStk8pIE
MwTzcw4ZuNabdhXTtmILoRL/g9n5iAj1KzZfLi8xWnBkZSV8zX/uq6xJAN9dyX8x
sf5/saq5XIf49JmZ4wCLuWM91EeMlHnxQ1nLbK0cnv8i+Bea4Csa8rKlnBaTTO5A
vyxnkIusJKIQMrBuAK6kzOZXCY80ptYfLhCUBN479PCD5REOf79Xl9kYIvPOqzIC
4u4oGoHFGMcWxbTopZpW6LC6Oo/dv7oUqkafobj00q8EmUXFaNYF3zBJaDcGsyxi
ZHaZMJwGOYocPeK+VL8iKUVBjJA2p7oBfK6DvrvLm2Zj606Mc4TJAxqA6UHq14c0
7k2QJv1kLMZAZL89anRj+u8+bFjO1v3WF/OA9hw8XLBWoesH9zP9c8dw81GKdxMc
VuWPldyD/8XRd4X2CRIotrU6hjQtNevdzU5sOCHgrEmq9EDkNt4sBMLvm/EnkcT1
eUTtNnBhml/B3NgPYwsWJo/fLa4r2AorWe837bwCy5lBClBMsizSHrWHoaoHGj6j
dGbuI12h9F4ZDzatHL59i7BlKH4rAOMjvwwh1LH2POFCrnwkfucJV+Gl0sq9c8h1
c/A/CGQrhXHDVsJqBfW4SUeNAWT349RbfyJCXWOQa7GqvJ+xsx5OwhcuH2mdQzdO
QZw2sm1j5sgTdgoCPrn/
=ityG
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] users and per user limits (tmpfs)

[Lennart Poettering]

On Tue, 28.04.15 12:03, Michał Zegan (webczat_...@poczta.onet.pl) wrote:

> (sorry, I haven't sent a reply to the list)
> What about namespacing and mounting tmpfs per user? You can specify a
> filesystem size when mounting tmpfs can't you?

Well, you can set this up with some packages for individual systems,
but this cannot work for general purpose systems since X11 uses /tmp
for placing its communication sockets. Moreover, when this is set up
the mount propagation from the user's namespace to the rest of system
must be turned off for the root directory, and this will break general
assumptions around mounting things through tools like "su" or "sudo"
then, as those mounts will not propagate to the rest of the system
either...

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] users and per user limits (tmpfs)

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

What if I will just make the / and similar mounts shared? Well, I am
not entirely sure about this whole terminology, not sure if I
understand it. About x11, in case of gnome I think a second x server
is spawned to service a request in context of a session (gnome 3.16)
so not sure if it would be a problem. Anyway something like on-disk
tmpfs with quotas may be safer/maybe easier to understand.

W dniu 2015-04-28 o 12:06, Lennart Poettering pisze:
> On Tue, 28.04.15 12:03, Michał Zegan (webczat_...@poczta.onet.pl)
> wrote:
> 
>> (sorry, I haven't sent a reply to the list) What about
>> namespacing and mounting tmpfs per user? You can specify a 
>> filesystem size when mounting tmpfs can't you?
> 
> Well, you can set this up with some packages for individual
> systems, but this cannot work for general purpose systems since X11
> uses /tmp for placing its communication sockets. Moreover, when
> this is set up the mount propagation from the user's namespace to
> the rest of system must be turned off for the root directory, and
> this will break general assumptions around mounting things through
> tools like "su" or "sudo" then, as those mounts will not propagate
> to the rest of the system either...
> 
> Lennart
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVP1zYAAoJEHb1CzgxXKwYwFEP/Ax3G+1JSIEytKMgAm2grtdS
pOdzC7FiOkyME0V2jj8FTRqydreYvASEmtzcW3eZgTp0dH4Uhb2buX8AD/IG6UiI
Qgr5xBqYIH3fyxnfzzlsexaHXOseWMMxbdzA1LiCsFI9l2zX+3MAorNoKDacvzz6
OMVXF87ycQl3j9VHrNt+aVSUDt2d62Ie5aQsRXRdEuz+biixH7EnjnhzoR1rl+75
PMkZotkzVy3RqA3bYWfCQEjaPSf3M1xvSeNqNFYv9doSTkozSMJFs+l7t4B+HJK/
bxeYPa0n/F/EpN2XHjEgGDXL/G5Z6D3/X6efaIMu3FW1B8Eok9xM3bWCzky3OsVE
MLuDywSmgzmRTxVl5xl1f1bdyeKTkzaQnbcUJGbnD8KIESjQssUlI20/1usPQRHC
DPyL+Wm722DnUc2TYnkeZHeP9zSZyuvQxxwk33A1qPu8+gcF+NofTpzvXSzNrsMm
Ggi/1Nln36vOUTEVKjbkAEKFSj8rvVvlxVZ9BoxDwG2vGATEdZxZSAGy1dPHzu1f
n9WLw8WctLFv7SOu9IIQgBfQyJzw1eO3qpEAirliycTnyF4uim8EcBBJ1/4HB7on
mDdd2JhSOryjozfmu9KuFi3Pr/0TG3Q60ANGQQuw1m3HjSAmVKJAWZbagCDegEK9
x/USoqOLfMNvbFkEQmgy
=XvJO
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] users and per user limits (tmpfs)

[Mantas Mikulėnas]

On Tue, Apr 28, 2015 at 1:06 PM, Lennart Poettering 
wrote:

> On Tue, 28.04.15 12:03, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
>
> > (sorry, I haven't sent a reply to the list)
> > What about namespacing and mounting tmpfs per user? You can specify a
> > filesystem size when mounting tmpfs can't you?
>
> Well, you can set this up with some packages for individual systems,
> but this cannot work for general purpose systems since X11 uses /tmp
> for placing its communication sockets.


That *should* work as long as the X server itself is started by the same
user (GDM 3.16 works that way because of Wayland, as does startx).


> Moreover, when this is set up
> the mount propagation from the user's namespace to the rest of system
> must be turned off for the root directory, and this will break general
> assumptions around mounting things through tools like "su" or "sudo"
> then, as those mounts will not propagate to the rest of the system
> either...
>

Wondering how the existing pam_namespace deals with this. Maybe / could be
kept shared, just /tmp made private.

I don't really like the idea of littering regular systems with even more
tangled mount namespaces, but still curious if this could work.

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

Re: [systemd-devel] users and per user limits (tmpfs)

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It may be possible, actually. Why oh why btrfs has no per user quotas?
this would be beneficial in some scenarios like this one.

W dniu 2015-04-28 o 12:17, Mantas Mikulėnas pisze:
> On Tue, Apr 28, 2015 at 1:06 PM, Lennart Poettering 
> mailto:lenn...@poettering.net>> wrote:
> 
> On Tue, 28.04.15 12:03, Michał Zegan (webczat_...@poczta.onet.pl 
> ) wrote:
> 
>> (sorry, I haven't sent a reply to the list) What about
>> namespacing and mounting tmpfs per user? You can specify a 
>> filesystem size when mounting tmpfs can't you?
> 
> Well, you can set this up with some packages for individual
> systems, but this cannot work for general purpose systems since X11
> uses /tmp for placing its communication sockets.
> 
> 
> That /should/ work as long as the X server itself is started by the
> same user (GDM 3.16 works that way because of Wayland, as does
> startx).
> 
> 
> Moreover, when this is set up the mount propagation from the user's
> namespace to the rest of system must be turned off for the root
> directory, and this will break general assumptions around mounting
> things through tools like "su" or "sudo" then, as those mounts will
> not propagate to the rest of the system either...
> 
> 
> Wondering how the existing pam_namespace deals with this. Maybe /
> could be kept shared, just /tmp made private.
> 
> I don't really like the idea of littering regular systems with even
> more tangled mount namespaces, but still curious if this could
> work.
> 
> -- Mantas Mikulėnas mailto:graw...@gmail.com>>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVP17NAAoJEHb1CzgxXKwYppQP/3FQ68SBzE1GpN2hCEgsXHIa
+gP6MsGwnsMppXD0wlfEuu55k4mmfm9unZ6c/+fwA+iTPIhVQceUAyj2X4euhzo/
jEzs7v05BiO9dVp+ZUPrgn9JLkJ67ve83f0rIgQgM4niXolK0gRhNUcT056V78Lk
tWxqqJ1rY6MSlCWVQNbNgxy5c+gK5J3sKPNbDscTh4iI/usPSkfWYFfLIi5PwKOA
33I47SRzhJ4RuUs6znNJNhitb/bpD6WyWQVyo+NaPDt/iTFNsGeIndYF7YoL36BY
bo3Xuc8B4whQDV6W82EIWDT7gF5FP/G8cu4Z9w3e+f0Il8h5nEjltyVewWHpHaaK
KpBYQ09URZqLjdDbeN8A2Ay3laMa5PrXesBHQ10jCLkDYNQm4M4yS1hcLjKzsECj
huzUGYmx00Bm2C15CR8JK56NFGT2tNmg+LOTqgVSoSZ4Qe5WpyHpzK3CViFkC9q9
IB+6lHnKn8FEZKw9SD+rr/o1qyGdDY0KeePT4eBRElyOeip4+gcQjM8PpDbximUm
Cidm/ymvJ64sUbjhHkoclLFMfQIS6Jhx2BcTwa/cf0L9Y1OYBOCKm2KYoRKe55qN
N5lM2x54gPs8nrmM3nu7zfsHQluPRIuPCkJ2r+BrgAf4RQmqGgdl/5J5kmSdwdIq
5ZfVSo3syK0QjvtBxhCN
=4bV+
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Both volatile and persistent journald logs

[Cam Hutchison]

Lennart Poettering  writes:

>On Thu, 23.04.15 06:58, Cam Hutchison (c...@xdna.net) wrote:

>> The specifics of my logging that is temporarily volatile is captured in
>> these rsyslog configs:
>> 
>> local1.*/tmp/log/dnsmasq.log
>> local4.*/tmp/log/ldap.log
>> if $syslogfacility-text == 'kern' and $msg contains 'firewall:' then
>> /tmp/log/firewall.log

>journald does not allow seperate log files or filter expressions,
>please use rsyslog or another syslog daemon for things like this.

I've got no real use for directing logs to files via these filter
expressions in a journald world. I'm happy with the filtering being
done on read-out instead of ingestion. These only go to separate
files because that's how syslog works.

But if I want to discriminate in order to direct logs to a volatile vs
persistent store then I would need some sort of pre-filtering and I can
see how that does not fit with journald's design.

However, even if I continue to use rsyslog with these filters, I don't
believe I will achieve what I want because the logs will first pass
through journald which will happily write them to its journal on
/var/log, creating the SSD write activity I'm trying to avoid.

For now I guess I'll just reduce the amount of logging. I should be able
to use NFLOG and ulogd2 to capture the firewall logs outside of
syslog/journald.

Thanks for your quick response.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] users and per user limits (tmpfs)

[Lennart Poettering]

On Tue, 28.04.15 12:11, Michał Zegan (webczat_...@poczta.onet.pl) wrote:

> What if I will just make the / and similar mounts shared? 

You have to turn off mount propagation for /tmp, so that the per-user
/tmp instance is not propagated to the rest of the system.

But after turning this off you cannot turn it on anymore, that's how
the kernel works. Which means if thereafter you try to mount something
over /mnt, then this will also not propagate to the rest of the sytem.

> Well, I am
> not entirely sure about this whole terminology, not sure if I
> understand it. About x11, in case of gnome I think a second x server
> is spawned to service a request in context of a session (gnome 3.16)
> so not sure if it would be a problem. Anyway something like on-disk
> tmpfs with quotas may be safer/maybe easier to understand.

The X11 socket is used for communication between users, hence
poly-instantiated /tmp will break some of X11 uses.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] need sponsor for systemd-cron

[Alexandre Detiste]

Hi,

I need a sponsor to upload an update of this package.

Development has pretty much staled (both in Debian package
& upstream), as this is a rather empty shell that lets
systemd do all the hard , and it is pretty much "done".

Cheers,

https://anonscm.debian.org/cgit/collab-maint/systemd-cron.git/tree/debian/changelog


  * New upstream version
  * Switch from Python2 to Python3
  * Set-up remove_stale_stamps as /etc/cron.weekly/systemd-cron
  * Properly attribute copyright of crontab.5
  * Closes: #766348 : generator does not parse ranges correctly
  * Closes: #767951 : "crontab -r user" will remove root crontab
  * Closes: #766756 : does not mail user in case of job errors
+ Recommends: exim4 | mail-transport-agent
  * Closes: #766757 : services should Requires=systemd-user-sessions.service
  * Closes: #766902 : @reboot jobs are run on package installation
  * Closes: #766764 : support ~/... to /home/user/... expansion
  * Closes: #766763 : support @annually
  * Closes: #770144 : ignore /etc/cron.d/*.dpkg-*
  * disable tests, as they break on pbuilder, and duplicate lintian tests
  * Closes: #776859 : don't call systemctl daemon-reload twice in postrm
  * Closes: #766345 : /usr/bin/crontab doesn't reject invalid crontabs
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] users and per user limits (tmpfs)

[Lennart Poettering]

On Tue, 28.04.15 13:17, Mantas Mikulėnas (graw...@gmail.com) wrote:

> > Moreover, when this is set up
> > the mount propagation from the user's namespace to the rest of system
> > must be turned off for the root directory, and this will break general
> > assumptions around mounting things through tools like "su" or "sudo"
> > then, as those mounts will not propagate to the rest of the system
> > either...
> 
> Wondering how the existing pam_namespace deals with this. Maybe / could be
> kept shared, just /tmp made private.

No, the propagation rules control if submounts of a mount are
propagated. If you intend to mount something on /tmp, then the
propagation rules of / are the ones that matter.

Also, if you disconnected propagation between two mount namespaces you
cannot reestablish the anymore.

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] need sponsor for systemd-cron

[Lennart Poettering]

On Tue, 28.04.15 12:39, Alexandre Detiste (alexandre.deti...@gmail.com) wrote:

> Hi,
> 
> I need a sponsor to upload an update of this package.

I figure this mail was supposed to go to some debian ML?

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] need sponsor for systemd-cron

[Alexandre Detiste]

sorry, sent to wrong list !!

2015-04-28 12:39 GMT+02:00 Alexandre Detiste :
> I need a sponsor to upload an update of this package.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Both volatile and persistent journald logs

[Lennart Poettering]

On Thu, 23.04.15 12:08, Cam Hutchison (c...@xdna.net) wrote:

> Lennart Poettering  writes:
> 
> >On Thu, 23.04.15 06:58, Cam Hutchison (c...@xdna.net) wrote:
> 
> >> The specifics of my logging that is temporarily volatile is captured in
> >> these rsyslog configs:
> >> 
> >> local1.*/tmp/log/dnsmasq.log
> >> local4.*/tmp/log/ldap.log
> >> if $syslogfacility-text == 'kern' and $msg contains 'firewall:' then
> >> /tmp/log/firewall.log
> 
> >journald does not allow seperate log files or filter expressions,
> >please use rsyslog or another syslog daemon for things like this.
> 
> I've got no real use for directing logs to files via these filter
> expressions in a journald world. I'm happy with the filtering being
> done on read-out instead of ingestion. These only go to separate
> files because that's how syslog works.
> 
> But if I want to discriminate in order to direct logs to a volatile vs
> persistent store then I would need some sort of pre-filtering and I can
> see how that does not fit with journald's design.
> 
> However, even if I continue to use rsyslog with these filters, I don't
> believe I will achieve what I want because the logs will first pass
> through journald which will happily write them to its journal on
> /var/log, creating the SSD write activity I'm trying to avoid.

Use Storage=volatile in journald.conf to turn off storage in /var.

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] Race condition on systemd-run --scope

[Lennart Poettering]

On Tue, 04.11.14 16:10, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

> Hi Lennart,
> 
> Were you able to figure out the problem? You were suspecting that we
> might not be getting cgroup empty notifications from kernel.

Finally fixed in git! It was a race in systemd-run itself, not in PID 1.

Sorry for the delay in fixing 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] users and per user limits (tmpfs)

[Mantas Mikulėnas]

On Tue, Apr 28, 2015 at 1:39 PM, Lennart Poettering 
wrote:

> On Tue, 28.04.15 13:17, Mantas Mikulėnas (graw...@gmail.com) wrote:
>
> > > Moreover, when this is set up
> > > the mount propagation from the user's namespace to the rest of system
> > > must be turned off for the root directory, and this will break general
> > > assumptions around mounting things through tools like "su" or "sudo"
> > > then, as those mounts will not propagate to the rest of the system
> > > either...
> >
> > Wondering how the existing pam_namespace deals with this. Maybe / could
> be
> > kept shared, just /tmp made private.
>
> No, the propagation rules control if submounts of a mount are
> propagated. If you intend to mount something on /tmp, then the
> propagation rules of / are the ones that matter.
>

I mean when /tmp itself is already a mountpoint, e.g. a bind mount on top
of itself (a common hack), then it has its own propagation mode, which will
be honored when mounting something at /tmp too, not just underneath.

(out) mount --bind /tmp /tmp
(out) mount --make-private /tmp
(out) unshare --mount
(in) mount -t tmpfs none /tmp
(out&in) findmnt

Really unnecessarily complex, but possible.

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

Re: [systemd-devel] users and per user limits (tmpfs)

[Lennart Poettering]

On Tue, 28.04.15 13:49, Mantas Mikulėnas (graw...@gmail.com) wrote:

> On Tue, Apr 28, 2015 at 1:39 PM, Lennart Poettering 
> wrote:
> 
> > On Tue, 28.04.15 13:17, Mantas Mikulėnas (graw...@gmail.com) wrote:
> >
> > > > Moreover, when this is set up
> > > > the mount propagation from the user's namespace to the rest of system
> > > > must be turned off for the root directory, and this will break general
> > > > assumptions around mounting things through tools like "su" or "sudo"
> > > > then, as those mounts will not propagate to the rest of the system
> > > > either...
> > >
> > > Wondering how the existing pam_namespace deals with this. Maybe / could
> > be
> > > kept shared, just /tmp made private.
> >
> > No, the propagation rules control if submounts of a mount are
> > propagated. If you intend to mount something on /tmp, then the
> > propagation rules of / are the ones that matter.
> >
> 
> I mean when /tmp itself is already a mountpoint, e.g. a bind mount on top
> of itself (a common hack), then it has its own propagation mode, which will
> be honored when mounting something at /tmp too, not just underneath.
> 
> (out) mount --bind /tmp /tmp
> (out) mount --make-private /tmp
> (out) unshare --mount
> (in) mount -t tmpfs none /tmp
> (out&in) findmnt
> 
> Really unnecessarily complex, but possible.

To my knowledge this is not how this works. If you overmount an
existing mount it's the parent mount and not the old mount whose
propagation matters.

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] DefaultDependencies of [Unit]

[Christian Seiler]

Am 2015-04-28 11:33, schrieb Lennart Poettering:

On Tue, 28.04.15 16:19, 樊超 (fcvi...@gmail.com) wrote:

I want to let my service run when shutdown,and it needn't close by
systemd,so can i set the DefaultDependencies of [Unit] to "no"?
I don't understand the meaning of DefaultDependencies.
It's [Unit] like this:
After=network.target network-online.target remote-fs.target
And I want to know if it matters when start the pc if I set
DefaultDependencies of [Unit] to "no"


Sure it matters. If DefaultDependencies=yes you get ordered after
basic.target and are shut down before shutdown.target is
reached. If you set DefaultDependencies=no you are started really
really early on (unless you explicitly order yourself after
basic.target). That means you'd have to make sure your service is
written in a way it can handle being run that early and doesn't 
assume

directories like /var are already mounted, or specific other services
already running. Similar, during shutdown if you continue to access
/var this late you will keep the mount for it busy, and accessing
other services might fail earlier than expected.


On the other hand, nothing prevents somebody from adding back select
dependencies by hand, i.e. if only Conflicts=shutdown.target is what
is to be avoided, then using DefaultDependencies=no but also
After=basic.target will make sure the service isn't started too
early (but kept until systemd's final process killing spree).

Christian

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

Re: [systemd-devel] [PATCH] udev: hwdb: Add trackpoint sensitivity settings for Lenovo X240 and 540p

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 28, 2015 at 11:07:42AM +0200, Hans de Goede wrote:
> Like the T440s these need the sensitity to be set significantly higher
> then the default of 128 for the trackpoint to be usable. Like with the
> T440s 200 seems to be a good value to get a reasonable but not too high
> sensitivity.
Applied.

I also made a follow up commit to compress the file a bit.

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

Re: [systemd-devel] [HEADSUP] Removal of shutdownd

[Colin Guthrie]

Daniel Mack wrote on 24/04/15 16:48:
> shutdownd was killed entirely. As a result, we have one less daemon
> lurking around, a nice DBus-API for something that used to be
> proprietary, and even less code:
> 
>  20 files changed, 727 insertions(+), 905 deletions(-)
> 
> However, this means that direct users of the shutdownd socket have to
> migrate to the DBus interface. We are only aware of one such user, which
> is Cockpit, and Stef Walter (Cc) already signaled his agreement on this
> change.
> 
> The patches are now pushed. They have been reviewed by Lennart before
> and I tested it for a while, but as always, we appreciate more testers
> for such a rework 

Is this what you do when you are not hacking the kernel? :)

Good work!!

C

-- 

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] fsckd needs to go

[Lennart Poettering]

On Fri, 03.04.15 14:58, Lennart Poettering (lenn...@poettering.net) wrote:

> systemd-fsckd would try to connect to some AF_UNIX/SOCK_STREAM socket
> in the fs, after forking and before execing fsck in the child, and
> pass the connected socket to fsck via the -C switch. If the socket is
> not connectable it would avoid any -C switch. With this simple change
> you can make this work for you: simply write a daemon (outside of
> systemd) that listens on that sockets and reads the progress data from
> it. Using SO_PEERCRED you can query which fsck PID this is from and
> use it to kill it. You could even add this to ply natively if you
> wish, since it's kinda strange to bump this all off another daemon in
> the middle, unnecessarily.

I implemented this now, and removed fsckd in the progress. The
progress data is now available on /run/systemd/fsck.progress which
should be an AF_UNIX/SOCK_STREAM socket. If you listen on it you will
get the raw fsck progress data though it. With SO_PEERCRED you can
figure out which fsck process is on the other side. If you do not
listen on it the progress data is instead printed to /dev/console
after converting it to percentage data.

Please test this, I only did some artifical testing myself, since I
don't use file systems that require fsck anymore myself.

Sorry again for communicating this so badly initially!

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-commits] TODO

[Lennart Poettering]

On Sun, 12.04.15 17:58, Tobias Hunger (tobias.hun...@gmail.com) wrote:

> Hi Lennart,
> 
> I just asked about the status of this, so I have links handy:
> 
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1423811
> https://bugs.archlinux.org/task/44016
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778970
> https://bugzilla.redhat.com/show_bug.cgi?id=1201964
> 
> All of these distros currently do not ship 219 or have 219 with said
> patch reverted.
> 
> First referrence to the issue on this list:
> http://lists.freedesktop.org/archives/systemd-devel/2015-February/028640.html
> 
> I was wondering about the status a couple of days ago:
> http://lists.freedesktop.org/archives/systemd-devel/2015-April/030540.html

Hmm, so, anyone found out anything useful about this? None of the
links above has anything useful really. I have never seen this issue
myself, so I kinda am relying on input from those who experiencing
this.

Is this still an issue with current, unpatched git (which has fsckd
removed among other changes).

What precisely hangs? 

What's the process list if this hangs? (use the debug shell, to get this)

What are the backtraces when this happens of the relevant programs?
i.e. of PID 1, of journald, and the other processes that run in
userspace?

what does "systemctl list-jobs" show?

does this happen with journald in the initrd in the same version as on
the host?

is this reproducible without initrd in the mix?

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] heads-up: chasing journal(?) related regression in 219 causing boot hang/fail

[Lennart Poettering]

On Mon, 27.04.15 17:49, Christian Hesse (l...@eworm.de) wrote:

> > As for the actual lockup, I'm afraid I don't understand at all
> > what is happening (I'm anot familiar at all with how journald
> > interacts with other services and D-Bus/logind).
> > 
> > So from my POV my best recommendation would be to revert commit
> > 13790add4 upstream for now until this gets understood and fixed
> > properly, especially if/when version 220 should be released. Breaking
> > booting is much worse than not being able to restart journald.
> 
> Any news about this one?
> Looks like everybody is waiting for a fix and nobody is working on it...

See:

http://lists.freedesktop.org/archives/systemd-devel/2015-April/031327.html

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] networkd: don't touch global forwarding setting

[Benedikt Morbach]

this inevitably leads to race conditions and also means that IPForward=yes on
one interface is equivalent to setting it on _every_ interface.
(except when it isn't, see below)

Suppose you have two networks

 * /etc/systemd/network/eth0.network
[Match]
Name=eth0

[Network]
Address=10.0.0.1/24
IPForward=yes

 * /etc/systemd/network/eth1.network
[Match]
Name=eth1

[Network]
Address=192.168.0.1/24

Depending on which interface gets brought up first, the forwarding situation
looks different.
If eth0 gets brought up first, it enables forwarding for itself and globally.
Then eth1 goes up and gets forwarding disabled as per the default.
However, if eth0 comes up later, it will enable forwarding globally, so in this
case both interfaces have forwarding enabled in the end.

To fix that, stop setting the global forwarding setting. This means that
IPForward needs to be set on all interfaces which should do forwarding
individually.

Also respect the default value from sysfs so that it can still be turned on
globally if desired.

systemd could still default to IPForward=no by using the default sysctl.conf
---
 src/network/networkd-link.c   | 23 ---
 src/network/networkd-network.c| 15 +++
 units/systemd-networkd.service.in |  2 +-
 3 files changed, 16 insertions(+), 24 deletions(-)

diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index ab115a0..933ed2f 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -1495,29 +1495,6 @@ static int link_set_ipv4_forward(Link *link) {
 if (r < 0)
 log_link_warning_errno(link, r, "Cannot configure IPv4 
forwarding for interface %s: %m", link->ifname);
 
-if (b) {
-_cleanup_free_ char *buf = NULL;
-
-/* If IP forwarding is turned on for this interface,
- * then propagate this to the global setting. Given
- * that turning this on has side-effects on other
- * fields, we'll try to avoid doing this unless
- * necessary, hence check the previous value
- * first. Note that we never turn this option off
- * again, since all interfaces we manage do not do
- * forwarding anyway by default, and ownership rules
- * of this control are so unclear. */
-
-r = read_one_line_file("/proc/sys/net/ipv4/ip_forward", &buf);
-if (r < 0)
-log_link_warning_errno(link, r, "Cannot read 
/proc/sys/net/ipv4/ip_forward: %m");
-else if (!streq(buf, "1")) {
-r = 
write_string_file_no_create("/proc/sys/net/ipv4/ip_forward", "1");
-if (r < 0)
-log_link_warning_errno(link, r, "Cannot write 
/proc/sys/net/ipv4/ip_forward: %m");
-}
-}
-
 return 0;
 }
 
diff --git a/src/network/networkd-network.c b/src/network/networkd-network.c
index 64c1b9c..e3f2299 100644
--- a/src/network/networkd-network.c
+++ b/src/network/networkd-network.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 
+#include "fileio.h"
 #include "conf-files.h"
 #include "conf-parser.h"
 #include "util.h"
@@ -33,6 +34,7 @@
 static int network_load_one(Manager *manager, const char *filename) {
 _cleanup_network_free_ Network *network = NULL;
 _cleanup_fclose_ FILE *file = NULL;
+_cleanup_free_ char *buf = NULL;
 char *d;
 Route *route;
 Address *address;
@@ -124,6 +126,19 @@ static int network_load_one(Manager *manager, const char 
*filename) {
 if (r < 0)
 return r;
 
+/* If IP forwarding is turned on globally, then respect
+ * that default in networkd as well. */
+r = read_one_line_file("/proc/sys/net/ipv4/ip_forward", &buf);
+if (r < 0)
+log_warning("Cannot read /proc/sys/net/ipv4/ip_forward");
+else if (streq(buf, "1"))
+network->ip_forward |= ADDRESS_FAMILY_IPV4;
+r = read_one_line_file("/proc/sys/net/ipv6/conf/all/forwarding", &buf);
+if (r < 0)
+log_warning("Cannot read 
/proc/sys/net/ipv6/conf/all/forwarding");
+else if (streq(buf, "1"))
+network->ip_forward |= ADDRESS_FAMILY_IPV6;
+
 /* IPMasquerade=yes implies IPForward=yes */
 if (network->ip_masquerade)
 network->ip_forward |= ADDRESS_FAMILY_IPV4;
diff --git a/units/systemd-networkd.service.in 
b/units/systemd-networkd.service.in
index 5a91b8e..527f6c0 100644
--- a/units/systemd-networkd.service.in
+++ b/units/systemd-networkd.service.in
@@ -12,7 +12,7 @@ ConditionCapability=CAP_NET_ADMIN
 DefaultDependencies=no
 # dbus.service can be dropped once on kdbus, and systemd-udevd.service can be
 # dropped once tuntap is moved to netlink
-After=systemd-udevd.service dbus.service network-pre.ta

Re: [systemd-devel] [PATCH] networkd: don't touch global forwarding setting

[Lennart Poettering]

On Tue, 28.04.15 18:55, Benedikt Morbach (benedikt.morb...@googlemail.com) 
wrote:

> this inevitably leads to race conditions and also means that IPForward=yes on
> one interface is equivalent to setting it on _every_ interface.
> (except when it isn't, see below)
> 
> Suppose you have two networks
> 
>  * /etc/systemd/network/eth0.network
> [Match]
> Name=eth0
> 
> [Network]
> Address=10.0.0.1/24
> IPForward=yes
> 
>  * /etc/systemd/network/eth1.network
> [Match]
> Name=eth1
> 
> [Network]
> Address=192.168.0.1/24
> 
> Depending on which interface gets brought up first, the forwarding situation
> looks different.
> If eth0 gets brought up first, it enables forwarding for itself and globally.
> Then eth1 goes up and gets forwarding disabled as per the default.
> However, if eth0 comes up later, it will enable forwarding globally, so in 
> this
> case both interfaces have forwarding enabled in the end.

Hmm? Not following?

If eth0 shows up first, then it will be configured, and thus the local
and global ip forwarding turned on. since the other interface hasn't
shown up yet/has not been configured the global setting doesn't matter
for it.

If eth1 shows up first, then it will be configured, and thus the local
ip forwaring turned off, the global is left untouched. Since the other
interface hasn't shown up yet/has not been configured the global
setting doesn't matter for it.

after both interfaces have been configured one will have local
forwarding on, one will have it off, and the global setting will be
on. so the right thing happened.

Hence, where is the problem you are trying to fix?

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] networkd: don't touch global forwarding setting

[Benedikt Morbach]

On Tue, Apr 28, 2015 at 7:36 PM, Lennart Poettering
 wrote:
> If eth1 shows up first, then it will be configured, and thus the local
> ip forwaring turned off, the global is left untouched. Since the other
> interface hasn't shown up yet/has not been configured the global
> setting doesn't matter for it.

when eth0 shows up the global is turned on. At least on my system
that enables forwarding for all currently present interfaces, including
eth1. Thus, in this case, both have forwarding enabled in the end.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] networkd: don't touch global forwarding setting

[Lennart Poettering]

On Tue, 28.04.15 19:51, Benedikt Morbach (benedikt.morb...@googlemail.com) 
wrote:

> On Tue, Apr 28, 2015 at 7:36 PM, Lennart Poettering
>  wrote:
> > If eth1 shows up first, then it will be configured, and thus the local
> > ip forwaring turned off, the global is left untouched. Since the other
> > interface hasn't shown up yet/has not been configured the global
> > setting doesn't matter for it.
> 
> when eth0 shows up the global is turned on. At least on my system
> that enables forwarding for all currently present interfaces, including
> eth1. Thus, in this case, both have forwarding enabled in the end.

But eth1 is not configured then and down, so it doesn't matter. And
when we configure it, we set the local switch to off, hence all is
good.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Introducing a desktop notification app

[George Karakougioumtzis]

Hello.
Based on a previous email that i sent to this list i wrote a python app
that notifies the user on the desktop about systemd logins, failed
systemd services, the status of some user defined services and also
monitors systemd files in /usr/lib/systemd and /etc/systemd/ directories
for modify,write events. I used well known python libs, all are
mentioned in the README file on the github page.

If someone could evaluate the code and if you think its of any benefit
for fedora i could make an rpm. There are actually two versions of the
program a minimal one in master branch and the full one on experimental
branch.
Note the app is temporary named systemd-notify.py, i will change the
name to systemd-desktop-notifications as to not to be confused with the
systemd-notify binary.
The link is on https://github.com/gkarakou/systemd-notify.py and the
instructions to install are on the README.md.
checkout the experimental branch
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [systemd-commits] TODO

[Tobias Hunger]

Hi Lennart,

I only cared since it was blocking systemd 219 in arch. I never had
any problem and assumed this was fixed since systemd 219 landed in
Arch a while back.

Best Regards,
Tobias


On Tue, Apr 28, 2015 at 5:48 PM, Lennart Poettering
 wrote:
> On Sun, 12.04.15 17:58, Tobias Hunger (tobias.hun...@gmail.com) wrote:
>
>> Hi Lennart,
>>
>> I just asked about the status of this, so I have links handy:
>>
>> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1423811
>> https://bugs.archlinux.org/task/44016
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778970
>> https://bugzilla.redhat.com/show_bug.cgi?id=1201964
>>
>> All of these distros currently do not ship 219 or have 219 with said
>> patch reverted.
>>
>> First referrence to the issue on this list:
>> http://lists.freedesktop.org/archives/systemd-devel/2015-February/028640.html
>>
>> I was wondering about the status a couple of days ago:
>> http://lists.freedesktop.org/archives/systemd-devel/2015-April/030540.html
>
> Hmm, so, anyone found out anything useful about this? None of the
> links above has anything useful really. I have never seen this issue
> myself, so I kinda am relying on input from those who experiencing
> this.
>
> Is this still an issue with current, unpatched git (which has fsckd
> removed among other changes).
>
> What precisely hangs?
>
> What's the process list if this hangs? (use the debug shell, to get this)
>
> What are the backtraces when this happens of the relevant programs?
> i.e. of PID 1, of journald, and the other processes that run in
> userspace?
>
> what does "systemctl list-jobs" show?
>
> does this happen with journald in the initrd in the same version as on
> the host?
>
> is this reproducible without initrd in the mix?
>
> 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-commits] TODO

[Lennart Poettering]

On Tue, 28.04.15 20:33, Tobias Hunger (tobias.hun...@gmail.com) wrote:

> Hi Lennart,
> 
> I only cared since it was blocking systemd 219 in arch. I never had
> any problem and assumed this was fixed since systemd 219 landed in
> Arch a while back.

OK, everyone who maintains this in distros, please provide me with the
data i asked for below, or otherwise this issue will stay unfixed in
the next release, too.

Martin, any chance you can help with this?

> On Tue, Apr 28, 2015 at 5:48 PM, Lennart Poettering
>  wrote:
> > On Sun, 12.04.15 17:58, Tobias Hunger (tobias.hun...@gmail.com) wrote:
> >
> >> Hi Lennart,
> >>
> >> I just asked about the status of this, so I have links handy:
> >>
> >> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1423811
> >> https://bugs.archlinux.org/task/44016
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778970
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1201964
> >>
> >> All of these distros currently do not ship 219 or have 219 with said
> >> patch reverted.
> >>
> >> First referrence to the issue on this list:
> >> http://lists.freedesktop.org/archives/systemd-devel/2015-February/028640.html
> >>
> >> I was wondering about the status a couple of days ago:
> >> http://lists.freedesktop.org/archives/systemd-devel/2015-April/030540.html
> >
> > Hmm, so, anyone found out anything useful about this? None of the
> > links above has anything useful really. I have never seen this issue
> > myself, so I kinda am relying on input from those who experiencing
> > this.
> >
> > Is this still an issue with current, unpatched git (which has fsckd
> > removed among other changes).
> >
> > What precisely hangs?
> >
> > What's the process list if this hangs? (use the debug shell, to get this)
> >
> > What are the backtraces when this happens of the relevant programs?
> > i.e. of PID 1, of journald, and the other processes that run in
> > userspace?
> >
> > what does "systemctl list-jobs" show?
> >
> > does this happen with journald in the initrd in the same version as on
> > the host?
> >
> > is this reproducible without initrd in the mix?
> >
> > Lennart
> >
> > --
> > Lennart Poettering, Red Hat
> 


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] Add VARIANT as a standard value for /etc/os-release

[Stephen Gallagher]

Some distributions (such as Fedora) are using the VARIANT field to
indicate to select packages which of several default configurations
they should be using. For example, VARIANT=Server provides a
different default firewall configuration (blocking basically
everything but SSH and the management console) whereas
VARIANT=Workstation opens many other ports for application
compatibility.

By adding this patch to the manual pages, we can standardize on a
cross-distribution mechanism for accomplishing this.

Fedora implementation details are available at
https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration
---
 man/os-release.xml | 13 +
 1 file changed, 13 insertions(+)

diff --git a/man/os-release.xml b/man/os-release.xml
index 
8f4ab10fed78b0f5c0c3842eb27bdef650fbdd93..71261ce77fa0c4f36553b182b54ef6b4a8ee0df7
 100644
--- a/man/os-release.xml
+++ b/man/os-release.xml
@@ -272,10 +272,23 @@
 or BUILD_ID=201303203.
 
 
   
 
+  
+VARIANT=
+
+
+A string identifying a specific variant or edition of the
+operating system. This may be interpreted by other packages in
+order to determine a divergent default configuration. This
+field is optional and may not be implemented on all systems.
+Examples: VARIANT=Server,
+VARIANT=Embedded
+
+  
+
 
 
 If you are reading this file from C code or a shell script
 to determine the OS or a specific version of it, use the
 ID and VERSION_ID fields,
-- 
2.3.6

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

Re: [systemd-devel] Looping too fast. Throttling execution a little

[John Morrissey]

On Tue, Apr 28, 2015 at 07:25:34PM -0400, John Morrissey wrote:
> I noticed this behavior recently on a Debian jessie system running systemd
> 215-17. systemd got itself in a loop like the previous reporter's:

Aaaand of course I forgot the URL to the previous post:

  http://lists.freedesktop.org/archives/systemd-devel/2015-February/028543.html

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

[systemd-devel] Looping too fast. Throttling execution a little

[John Morrissey]

On 18 Feb 2015, at 18:47, Lennart Poettering  wrote:
> Hmm, this appears to be caused by a timer that is not reset. First the
> timer fd is set to the earliest possible trigger, then epoll_wait() is
> entered, which immediately quites. Then the tiemrfd elapse counter is
> read which is 1.
> 
> It would be interesting to figure out which timer this is.
> 
> To make this work, can you reproduce the issue, then use gdb:
> 
> 1. Type "gdb" to start it
> 2. Type "attach 1" to attach to PID 1
> 3. Type "b source_dispatch" to set a break point on the source_dispatch 
> function
> 4. Type "c" to continue execution
> 5. This should then break on the next execution of the source_dispatch 
> function
> 6. This should happen immediately, after all PID 1 is busy looping
>   around a timer. Use "p s->description" to get a short description
>   string for the event that is being dispatched. In fact, please use
>   "p *s" to get all data about the event, and paste it here.

I noticed this behavior recently on a Debian jessie system running systemd
215-17. systemd got itself in a loop like the previous reporter's:

--
recvmsg(42, 0x7fff3ea64d00, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 
EAGAIN (Resource temporarily unavailable)
timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={0, 1}}, 
NULL) = 0
epoll_wait(4, {{EPOLLIN, {u32=3, u64=3}}}, 36, 0) = 1
clock_gettime(CLOCK_BOOTTIME, {1959524, 957887776}) = 0
read(3, "\1\0\0\0\0\0\0\0", 8)  = 8
recvmsg(42, 0x7fff3ea64d00, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 
EAGAIN (Resource temporarily unavailable)
--

and became pretty much unresponsive (daemon restarts took minutes, if they
ever completed, etc.).

Here's the gdb output; there's no description on the variable in question,
so I had gdb emit all struct members for several loop iterations:

(gdb) p s->description
There is no member named description.
(gdb) p *s
$1 = {n_ref = 1, event = 0x17f85, userdata = 0x7f85414b4bf0, prepare = 0x0,
  type = -16, enabled = 2, pending = false, dispatching = false, floating = 
false,
  priority = 8455620127265646592, pending_index = 1, prepare_index = 0,
  pending_iteration = 1095177008, prepare_iteration = 32645, sources_next = 0x1,
  sources_prev = 0x7f8540dae40e, {io = {
  callback = 0x7f8540ff3850 , fd = 1095414960, events 
= 32645,
  revents = 1, registered = false}, time = {
  callback = 0x7f8540ff3850 , next = 140210302792880,
  accuracy = 1, earliest_index = 1087651621, latest_index = 32645}, signal 
= {
  callback = 0x7f8540ff3850 , siginfo = {
ssi_signo = 1095414960, ssi_errno = 32645, ssi_code = 1, ssi_pid = 0,
ssi_uid = 1087651621, ssi_fd = 32645, ssi_tid = 1095177008, ssi_band = 
32645,
ssi_overrun = 1087684037, ssi_trapno = 32645, ssi_status = 1086746592,
ssi_int = 32645, ssi_ptr = 140731408831079, ssi_utime = 140731408830816,
ssi_stime = 0, ssi_addr = 140731408830848,
__pad = 
"0\aKA\205\177\000\000\260\264JA\205\177\000\000\tWY@\205\177\000\000\000\000\000\000\000\000\000\000\224UY@\205\177\000\000\000\000\000\000\000\000\000"},
  sig = 465584131}, child = {callback = 0x7f8540ff3850 
,
  siginfo = {si_signo = 1095414960, si_errno = 32645, si_code = 1, 
_sifields = {
  _pad = {1087651621, 32645, 1095177008, 32645, 1087684037, 32645, 
1086746592,
32645, -1784556953, 32766, -1784557216, 32766, 0, 0, -1784557184, 
32766,
1095436080, 32645, 1095414960, 32645, 1079596809, 32645, 0, 0, 
1079596436,
32645, 0, 0}, _kill = {si_pid = 1087651621, si_uid = 32645}, _timer 
= {
si_tid = 1087651621, si_overrun = 32645, si_sigval = {
  sival_int = 1095177008, sival_ptr = 0x7f8541471330}}, _rt = {
si_pid = 1087651621, si_uid = 32645, si_sigval = {sival_int = 
1095177008,
  sival_ptr = 0x7f8541471330}}, _sigchld = {si_pid = 1087651621,
si_uid = 32645, si_status = 1095177008, si_utime = 140210295061957,
si_stime = 140210294124512}, _sigfault = {
si_addr = 0x7f8540d43f25 , si_addr_lsb = 
4912},
  _sigpoll = {si_band = 140210295029541, si_fd = 1095177008}, _sigsys = 
{
_call_addr = 0x7f8540d43f25 ,
_syscall = 1095177008, _arch = 32645}}}, pid = 465584131, options = 
0},
defer = {callback = 0x7f8540ff3850 }, post = {
  callback = 0x7f8540ff3850 }, exit = {
  callback = 0x7f8540ff3850 , prioq_index = 
1095414960}}}
(gdb) cont
Continuing.

Breakpoint 1, source_dispatch (s=0x7ffe95a1d080)
at ../src/libsystemd/sd-event/sd-event.c:1976
1976in ../src/libsystemd/sd-event/sd-event.c
(gdb) p *s
$2 = {n_ref = 1, event = 0x17f85, userdata = 0x7f85414b4bf0, prepare = 0x0,
  type = -16, enabled = 2, pending = false, dispatching = false, floating = 
false,
  priority = 8455620127265646592, pending_index = 1, prepare_index = 0,
  pending_iteration = 1095177008, prepare_iteration = 32645, sources_next = 0x1,
  s

[systemd-devel] tmpfiles versus tmpwatch

[Roger Qiu]

Hello all,

I'm planning to use tmpwatch's `fuser` feature.

But I'd prefer to run this simple service using systemd's tmpfiles.
Does systemd tmpfiles support running `fuser` so that way it won't 
delete any files that have an open file descriptor?


I couldn't see any mention of in the docs and source code 
(https://github.com/systemd/systemd/blob/master/src/tmpfiles/tmpfiles.c).


Thanks,
Roger

--
Founder of Matrix AI
http://matrix.ai/
+61420925975

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

Re: [systemd-devel] systemd-nspawn and IPv6

[Jörg Thalheim]

> Well, would that enable automatic, correcting routing between the
> container and the host's external network? That's kinda what this all
> is about...
> 
> Lennart
> 

In case we know, which interface provides the external network, it is also 
possible to use proxy ndp 
to give containers routeable ips:

sysctl -w net.ipv6.conf..proxy_ndp=0
ip -6 neigh add proxy  dev 

where  is the external interface and  is the container ip.
Proxy NDP will reply with Neighbor Advertisement on the interface in
question if somebody has sended a Neighbor Solicitation messages for an added 
ip (similar to ARP Requests/Response).

To give a container an ip from the subnet advertised on the external interface, 
it would be required to proxy router advertisements between external interface 
and bridge (or veth pair).
Afaik their is no such proxy for router advertisements, so it would required to 
bridge the external interface with the bridge (or the host side of the veth 
pair), 
which would break the isolation between external and internal network. (Maybe 
somebody has a better solution on how to get an ip via router advertisement)

The cool thing of having 1 routeable ip per container is, you have no longer 
conflicts with port numbers and can actually bind port 80 multiple times for 
example. About security concerns:
why not whitelist ports forwarded from external with the --port parameter of 
systemd-nspawn and block everything else. 
The only thing port forwarding hides, is the destination ip source, but does 
not expose if the ip addressed is assigned to the host, a container or even a 
complete different host, which uses this host as a router.
Also private addresses would still require to NAT traffic from container to the 
external network, which requires a lot nasty protocol hacks (ipsec, ftp, SIP, 
...)

Ideally nspawn could rely on a service which would either forward router 
advertisements of an external interface or fallback to private addresses in 
case, the host does not have external network configured.

About ULA addresses (fd00::/8): couldn't these be generated using the 
machine-id of a container (does every container has a machine-id? is the mac 
address stable for containers)? 
We have 128 - 8 = 120 bit free, however it is recommend to not use the hole ULA 
address space but limit it to a prefix.
What also always works is using link-local addresses (not for the containers, 
because link local addresses are awkward to type, because they always needs to 
include the interface, but it could be used for the host part in the default 
gateway)


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

Re: [systemd-devel] tmpfiles versus tmpwatch

[Kai Krakow]

Roger Qiu  schrieb:

> I'm planning to use tmpwatch's `fuser` feature.
> 
> But I'd prefer to run this simple service using systemd's tmpfiles.
> Does systemd tmpfiles support running `fuser` so that way it won't
> delete any files that have an open file descriptor?
> 
> I couldn't see any mention of in the docs and source code
> (https://github.com/systemd/systemd/blob/master/src/tmpfiles/tmpfiles.c).

I don't think it will or ever will but I'm not a dev.

The point is: tmpwatch's fuser feature is IMHO just a countermeasure for 
filesystems mounted with noatime in combination with wrongly behaving 
software which has long living processes opening files in /tmp. That's wrong 
by design.

Such software should put such files in /var/tmp (which is, according to unix 
standards, volatile, too, but would survive reboots and files should stay 
around 30 days without usage) or in /var/{cache,spool,lib}. For /var/cache 
subdirectories you could setup tmpfiles or tmpwatch - whatever is more 
appropriate to you.

Files with very long open times and never being touched in a long time just 
don't belong into /tmp. And if you want to ensure that a file isn't 
accidently deleted too early, don't enable noatime. Use relatime (or maybe 
lazytime from the next kernel versions which is much more posix conform).

-- 
Replies to list only preferred.

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