Re: [systemd-devel] bind mounts are not delayed until the underlying fs gets mounted

[Frank Steiner]

Andrei Borzenkov wrote


>> This sounds like it should work in the scenario as /export2/rpm is
>> clearly beneath /export2. But there are no matching depencendies
>> in the the /run/systemd/generator/*.mount files. So is it safe to 
>> assume the error only occurs due to the old systemd version?
>>
> 
> These dependencies are added internally, they are not found in any
> on-disk unit files.
> 
> Check with "systemctl show mount-unit".

There seems to sth. wrong indeed. It shows:

Where=/rpm-export
What=/dev/sda1
Options=rw,relatime,rw,space_cache,subvolid=257,subvol=/@/export2/rpm
...

When I unmount /rpm-export and remount it, the command shows the
correct values afterwards:

Where=/rpm-export
What=/dev/mapper/raid2--iscsi-backup--export
Options=rw,relatime,rw,attr2,inode64,sunit=8,swidth=1024,noquota
...

So at the first try during boot systemd fails to detect the
dependency :-(

> This should work in your version as well. If it does not, the only idea
> I have is that /export2/rpm unit is processed before /export2 and so
> does not "know" about this dependency yet.
 
I guess so. The default ordering mechanism should be "from top to bottom"
in fstab, but it looks like this vanishes for entries delayed by _netdev.
Maybe systemd collects all _netdev entries for later activation but
then forgets to re-order them? 

cu,
Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. BioinformatikMail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17   Phone: +49 89 2180-4049
80333 Muenchen, Germany   Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Settings in /etc/systemd/journald.conf dont work

[Tommy_Lu]

Hello

I am an old retired boy from German and a short-time visitor here in 
this list. And I apologize, because I put my user-question here. But 
unfortunately nowhere in the network i can found a solution or people 
who have sufficient expertise. My Problem relates to "journalctl". I 
want that Entries in my journal only the last 7 days are kept, 
regardless of Journals Filesize. Therefor I have entered in the 
/etc/systemd/journald.conf the following parameters:

Storage = auto
MaxRetentionSec = 1week

But nothing happens. The entries (older 7 days) will not be removed in 
runtime or after reboot. Even the entries in the "User-Actions-Journal" 
are not removed . Only when I reboot the Journals daemon the 
Systemjournal is completely emptied, what is also wrong. However, the 
Userjournal will remain unchanged and continue to contain month old 
data. What I would have to stop or do that I get these same 7 Days for 
both journals. I know that there are also "size-settings" are possible, 
but I'd like to set these 7-day cycle.


I use "Debian Jessie" as a Debootstrap-Setup with some selected LXDE 
components for a custom Desktop_GUI.

apt show systemd
   Package: systemd
   Version: 215-17+deb8u3

Can anyone help me with a advice? Many thanks for your help.
Thomas

ps
Also sorry…. it's a 40-years-ago-school-english...

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

Re: [systemd-devel] Variables in the [Unit] section of a server

[Steve Dickson]

On 01/23/2016 11:33 AM, Armin K. wrote:
> On 23.01.2016 17:28, Armin K. wrote:
>>> On 01/13/2016 10:51 AM, Steve Dickson wrote:
 Hello,

 Is is possible to set a variable in the [Unit]
 section of a service?

 For example in rpc-gssd.service there is
 ConditionPathExists=/etc/krb5.keytab

 but for some installation the krb5.keytab
 is in a different place. The rpc.gssd daemon
 can be told this by setting a command line
 argument from the EnvironmentFile.

 So people have to edit both the EnvironmentFile
 and the rpc-gssd.service to make this change. 

 So it would be nice if only the EnvironmentFile
 need to be edit and the change would happen
 in both places. 

 Possible?

 steved.
>>
>> I'm sorry I'm not responding to the original mail, as I just subscribed
>> yesterday to this list.
>>
>> I am not sure I fully understand what you want, but I think this might do it:
>>
>> [Unit]
>> Description=test
>>
>> [Service]
>> Type=oneshot
>> Environment=TEST=blah
>> EnvironmentFile=-/etc/systemd/system/test-env
>> ExecStart=/etc/systemd/system/test ${TEST}
>> TimeoutSec=0
>> RemainAfterExit=yes
>>
>> The /etc/systemd/system/test is a script that prints $1, depending on what is
>> being passed to it. When env file is not present, it prints the TEST from the
>> unit file. When env file is present, and TEST is set to something else, it
>> prints its value. Is that what you are looking for?
>>
>> Cheers
>>
> 
> Ugh, sorry. You asked for the [Unit] section, not the [Service] section.
> From what I see, it doesn't yet seem to be possible:
> 
> [/etc/systemd/system/test.service:2] Unknown lvalue 'Environment' in section 
> 'Unit'
> [/etc/systemd/system/test.service:4] Path in condition not absolute, 
> ignoring: $TEST
> 
> You can always use some kind of hackery in ExecStartPre, but I don't think 
> that's
> what anyone wants.
> 
Well its to bad ConditionPathExists is not part of the [Service] section
so I could use a shell variable... 

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

Re: [systemd-devel] systemd-nspawn

[Mantas Mikulėnas]

On Tue, Feb 2, 2016 at 3:06 PM, Pascal  wrote:

> hi it's me again ;-),
>
> with options *network-bridge* or *network-veth*, you « need » to
> configure network host card *ve-container@if2* and network container card
> *host0@if5*..
>
> with my request, the idea would be to not disconnect the loopback device
> and so, without network configuration, the container could simply expose 
> network
> services throught the host...
>
> instead of the option *port* to run with the option *private-network*,
> this could be a new option (lo-network) that doesn't totally disconnect the
> network of the two systems, but leaves only loopback device...
>

Nice idea, but no. Systemd can't pick and choose which interfaces to
"disconnect" and which to keep – Linux network namespaces are an
all-or-nothing thing. You can only *move* interfaces between namespaces
(e.g. host0 gets moved from the main NS to the container), but you cannot
have the same interface in multiple namespaces at once.

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

Re: [systemd-devel] Settings in /etc/systemd/journald.conf dont work

[Kai Krakow]

Am Tue, 2 Feb 2016 11:09:51 +0100
schrieb Tommy_Lu :

> Hello
> 
> I am an old retired boy from German and a short-time visitor here in 
> this list. And I apologize, because I put my user-question here. But 
> unfortunately nowhere in the network i can found a solution or people 
> who have sufficient expertise. My Problem relates to "journalctl". I 
> want that Entries in my journal only the last 7 days are kept, 
> regardless of Journals Filesize. Therefor I have entered in the 
> /etc/systemd/journald.conf the following parameters:
> Storage = auto
> MaxRetentionSec = 1week
> 
> But nothing happens. The entries (older 7 days) will not be removed
> in runtime or after reboot. Even the entries in the
> "User-Actions-Journal" are not removed . Only when I reboot the
> Journals daemon the Systemjournal is completely emptied, what is also
> wrong. However, the Userjournal will remain unchanged and continue to
> contain month old data. What I would have to stop or do that I get
> these same 7 Days for both journals. I know that there are also
> "size-settings" are possible, but I'd like to set these 7-day cycle.
> 
> I use "Debian Jessie" as a Debootstrap-Setup with some selected LXDE 
> components for a custom Desktop_GUI.
> apt show systemd
> Package: systemd
> Version: 215-17+deb8u3
> 
> Can anyone help me with a advice? Many thanks for your help.
> Thomas

I think the following might happen: both limits (size-based and
time-based) still apply, and journald respects the limit that keeps
more journal entries. Thus, you may want to try to set SystemMaxUse to
a much smaller limit.

More likely: I pretty sure time-based retention can only be applied
during file rotation - means: when your per-file size limit is high, the
contained entries will not be removed until file rotation occurs - but
then they all are going to removed as the whole log file (all or
nothing).

Thus, you may also want experimenting with lowering the per-file size
limits so rotation occurs more often.

But this also means you will never get rid of old entries on a
per-hour, not even a per-day granularity. The settings only guarantee
that you always see the entries within the limits. It does not,
however, guarantee that you will never see entries outside of the
limits. But from an admin point of view that is perfectly sensible.
This is the guarantee you actually want.

So your only way is to tighten the granularity of log files, then use
the limit settings to throw away whole log database files.

If you want to see only specific entries back to some point in time,
you have to use a date filter when calling journalctl. Retention is
totally different approach and works as designed. There's a difference
between retention and filtering.

-- 
Regards,
Kai

Replies to list-only preferred.

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

Re: [systemd-devel] systemd-nspawn

[Pascal]

hi it's me again ;-),

with options *network-bridge* or *network-veth*, you « need » to configure
network host card *ve-container@if2* and network container card *host0@if5*
..

with my request, the idea would be to not disconnect the loopback device
and so, without network configuration, the container could simply
expose network
services throught the host...

instead of the option *port* to run with the option *private-network*, this
could be a new option (lo-network) that doesn't totally disconnect the
network of the two systems, but leaves only loopback device...

regards, lacsaP.

2016-01-25 18:39 GMT+01:00 Pascal :

> hi again,
>
> some calrification : I'm on archlinux and systemd version is
> systemd 228
> +PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP
> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN
>
> the systemd-nspawn documentation
>  says
>
> *-p, --port=If private networking is enabled, maps an IP port on the
> host onto an IP port on the container. Takes a protocol specifier (either
> "tcp" or "udp"), separated by a colon from a host port number in the range
> 1 to 65535, separated by a colon from a container port number in the range
> from 1 to 65535. The protocol specifier and its separating colon may be
> omitted, in which case "tcp" is assumed. The container port number and its
> colon may be omitted, in which case the same port as the host port is
> implied. This option is only supported if private networking is used*,
> such as with --network-veth or --network-bridge=.
>
> with "systemd-nspawn -b -D my_container --private-network --port 1234", 
> *private
> networking is enabled* and
> we could imagine that the port association is done on the loopback
> interface, no ?
>
> it would be good for isolating container without having to set a network
> configuration (bridge or other)...
>
> for example, in my container, I've redis and nodebb, with redis listening
> on 127.0.0.1:6379 and nodebb on 127.0.0.1:4567, and, on my host, nginx
> which listening on 0.0.0.0:80 and act as reverse proxy for nodebb : with  
> "systemd-nspawn
> -b -D nodebb --private-network --port 4567" and without other network
> setting, I could access nodebb just with "proxy_pass http://127.0.0.1:4567;;
> in nginx.
>
> regards, lacsaP.
>
> 2016-01-25 0:10 GMT+01:00 Pascal :
>
>> hi,
>>
>> I'm discovering and playing with systemd-nspawn and I must say it's
>> pretty cool !
>>
>> I have a question about the --port option : why it doesn't work on the
>> loopback with --private-network option ?
>>
>> eg "systemd-nspawn -b -D my_container --private-network --port 1234"
>> doesn't connect the port 1234 of the loopback host with the port 1234 of
>> the loopback container.
>>
>> regards, lacsaP.
>>
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel