Re: [systemd-devel] 2017: systemd-readahead?

[Kai Krakow]

Am Mon, 6 Feb 2017 21:52:09 +0100
schrieb Lennart Poettering :

> On Tue, 10.01.17 12:14, Che (comandantegri...@gmail.com) wrote:
> 
> > What's the 2017 status of systemd-readahead..? Permanently dead?  
> 
> Well, we removed it from the systemd tree, and suggested other folks
> to take it over. I am not aware that anyone did.

Gentoo extracted a snapshot of the last git tree containing readahead.
The build then configures the tree to only build the readahead binary.
I think it needs to be patched from time to time to still build with
updated system dependencies but currently I didn't see a version bump
yet.

However, I finally ditched it. I figured it will slow down boot of an
aging system. Instead, I added bcache to my spinning rust plus an
affordable SSD. This works very well and reduces boot times much better
than readahead (by a factor of at least 5).

The ebuild contents should give you a clue how it's done:

https://packages.gentoo.org/packages/sys-apps/systemd-readahead

-- 
Regards,
Kai

Replies to list-only preferred.

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

Re: [systemd-devel] Storing Data on systemd bus

[Lennart Poettering]

On Mon, 06.02.17 12:54, guhan balasubramanian (guhan@gmail.com) wrote:

> Hi,
> 
> I've followed the tutorial on the 0pointer blog [1] for creating a 'system'
> service.
> I am currently held up with two questions which would help me come up with
> a better design for my "inventory" program.
> 
>1. Is it possible to use sd-bus API as an inventory to store and
>retrieve data? Whether sd-bus internally would store the data in the bus
>forever until deleted, something like a message queue?

D-Bus is an IPC system, for delivering control messages between
processes.

It's not a storage system, and while messages are queued on it, you
cannot read them out of order, the messages have to be "small", and
you will be kicked off the bus if you stop processing your incoming
messages for too long.

Lennart

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

Re: [systemd-devel] How to disable Predictable Network Interface Names using a drop-in?

[Lennart Poettering]

On Fri, 20.01.17 14:51, Patrick Schleizer (patrick-mailingli...@whonix.org) 
wrote:

> Hi,
> 
> I've learned about the kernel parameter and symlink ways to disable
> predictable network interface names. However, as a Debian derivative, it
> would be much cleaner using a drop-in to disable it.
> 
> Is there some drop-in directory foo.service.d that can be used to
> disable it?

ln -s /dev/null /etc/systemd/network/99-default.link

Lennart

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

Re: [systemd-devel] How to disable Predictable Network Interface Names using a drop-in?

[Lennart Poettering]

On Sat, 21.01.17 21:20, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:

> On Fri, Jan 20, 2017 at 02:51:00PM +, Patrick Schleizer wrote:
> > I've learned about the kernel parameter and symlink ways to disable
> > predictable network interface names.
> 
> What would be the "symlink way"?

Linking the relevant .link file to /dev/null in /etc.

> Will predictable network names still play nice with the old udev
> way?

Well, if you have configuration, it's honoured.

> I cannot make my brain remember that my notebook has enp0s25 and
> wlp3s0, and would like to have eth0 and wlan0 again (or net0 and net1,
> or wired0 and wless0, if it is a bad idea to move the interfaces back
> to the kernel namespaces), while keeping the advantage of having
> predictable network names for USB network interfaces that I regularly
> plug in as well.
> 
> Will placing a /etc/udev/rules.d/70-persistent-network.rules
> that renames enp0s25 to wired0 and wlp3s0 to wless0 play nice, it is
> that asking for trouble?

Well, if you use names from the kernel's own namespace (i.e. ethXYZ or
wlanXYZ), yes, you#d be asking for trouble, since you#d be racing
against the kernel's naming.

However, if you pick your own names outside of the kernel's
namespaces, then all is good, and that's actually what we
recommend. (Though I'd do it by dropping in some .link files with the
right [Match] sections to make this happen, not bother with udev
rules, but either works)

Lennart

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

[systemd-devel] 2017: systemd-readahead?

[Che]

What's the 2017 status of systemd-readahead..? Permanently dead?


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

Re: [systemd-devel] 2017: systemd-readahead?

[Lennart Poettering]

On Tue, 10.01.17 12:14, Che (comandantegri...@gmail.com) wrote:

> What's the 2017 status of systemd-readahead..? Permanently dead?

Well, we removed it from the systemd tree, and suggested other folks
to take it over. I am not aware that anyone did.

Lennart

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

[systemd-devel] Storing Data on systemd bus

[guhan balasubramanian]

Hi,

I've followed the tutorial on the 0pointer blog [1] for creating a 'system'
service.
I am currently held up with two questions which would help me come up with
a better design for my "inventory" program.

   1. Is it possible to use sd-bus API as an inventory to store and
   retrieve data? Whether sd-bus internally would store the data in the bus
   forever until deleted, something like a message queue?
   2. If above question has a positive answer, I am trying to get and set
   properties by creating a service (Example 1 in Reference - Busctl Man
   Page ). I
   am doing this on the system bus, but I am not able to '*store the data
   in the bus'* as in the example. For now, I am only able to store data in
   the '*process memory' *as global variables.  [2] doesn't seem to help
   much as the bus is not storing the data using SD_BUS_WRITABLE_PROPERTY. Is
   there a reference code or documentation I can refer to?

Please advise and thanks in advance!

-Guhan

References:
1. http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html
2.
https://github.com/systemd/systemd/blob/master/src/libsystemd/sd-bus/test-bus-objects.c
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Take me off your list

[Jeff Hall]

Please remove me

Regards,
Jeff Hall
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to disable Predictable Network Interface Names using a drop-in?

[Marc Haber]

On Fri, Jan 20, 2017 at 02:51:00PM +, Patrick Schleizer wrote:
> I've learned about the kernel parameter and symlink ways to disable
> predictable network interface names.

What would be the "symlink way"?

Will predictable network names still play nice with the old udev way?
I cannot make my brain remember that my notebook has enp0s25 and
wlp3s0, and would like to have eth0 and wlan0 again (or net0 and net1,
or wired0 and wless0, if it is a bad idea to move the interfaces back
to the kernel namespaces), while keeping the advantage of having
predictable network names for USB network interfaces that I regularly
plug in as well.

Will placing a /etc/udev/rules.d/70-persistent-network.rules
that renames enp0s25 to wired0 and wlp3s0 to wless0 play nice, it is
that asking for trouble?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RequiresMountsFor and the noauto option.

[Lennart Poettering]

On Mon, 23.01.17 11:13, NeilBrown (ne...@suse.com) wrote:

> 
> hi,
>  according to "man systemd.unit" :
> 
>RequiresMountsFor=
>Takes a space-separated list of absolute paths.
>Automatically adds dependencies of type Requires= and
>After= for all mount units required to access the
>specified path.
> 
>Mount points marked with noauto are not mounted
>automatically and will be ignored for the purposes of
>this option. If such a mount should be a requirement for
>this unit, direct dependencies on the mount units may be
>added (Requires= and After= or some other combination).

Hmm, this is weird. This is actually not what happens. The
documentaiton is simply not correct here. That's a bug we need to
fix. I filed a bug about this now:

https://github.com/systemd/systemd/issues/5249

What actually happens is that RMF= adds After= for all prefix mount
units, but Requires= only to those which have a fragment file
(i.e. are explicitly configured). The "noauto" flag is not checked.

Sorry for the confusion.

>  If the documentation is wrong, and the code is correct, would it be
>  possible to get "AfterMountsFor=" as that is the functionality that I
>  really want.

I figure we could add that. Please file an RFE on github.

Lennart

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

Re: [systemd-devel] "libsystemdexec/systemd-run --exec-from-unit"

[Lennart Poettering]

On Sun, 29.01.17 01:56, Colin Walters (walt...@verbum.org) wrote:

> Hey so, this is is a half-baked thought, but here goes:
> 
> One problem I've hit when trying to use systemd unit file features
> is that they only work when executed by systemd.  Let's take the
> example of User=, but it applies to tons of other ones too.
> 
> Wait you ask - your service runs under systemd, why do you care
> about running it not under systemd?  The main case I hit is I often
> want to run my service under a debugger.
> 
> If I just do gdb /usr/lib/myservice ... it will run as root.  Now of
> course, I could runuser myservice gdb --args /usr/lib/myservice.
> But as a unit file gains more features, from WorkingDirectory to
> ProtectSystem=, I find myself wanting something like:
> 
> systemd-run --exec-from-unit myservice.service 
> /path/to/myservice/src/myservice
> 
> Basically exec an uninstalled copy from the builddir.  Or alternatively,
> do a `sudo make install` type thing and:
> 
> systemd-run --exec-from-unit myservice.service --execstart-args gdb --args
> 
> Has anyone else hit this?  Am I missing something obvious?
> 
> Taking this out a little bit, I could imagine having the systemd unit  -> 
> execprep
> as a shared library.  This would make it easier to use inside daemon
> code itself.  This solves a few scenarios like having the service itself
> spawn helper processes that don't quite fit into the template model.

Well, that would require us to duplicate much of the execution context
setup in this tool. And that's harder than it sounds, since we inherit
a lot of different bits from PID 1 which is much harder to do if you
are not a child of PID 1...

Since the usecase for this is debugging, I wonder if it would be
better to go the other way: provide a way how you can start a unit as
usual, but make systemd wait for a debugger to attach immediately
before executing the actual daemon binary. Then, we could provide a
tool "systemd-gdb" or so, which uses this for spawning a service and
immediately attaches to it by invoking gdb with the right command line
parameters.

This way you'd have the big benefit that what you debug is as close as
possible to what happens without debugging as it possibly could get.

I figure this could relatively easily be implemented by implementing a
new job mode "debug" or so, which would have the effect that any unit
started like this would simply raise SIGSTOP right before execve().

(But if we have that we could even build on that, and turn off the
watchdog logic when this is used, since it fucks up all good
debugging).

Lennart

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

Re: [systemd-devel] How to attach a .socket file to all the network namespaces

[Lennart Poettering]

On Mon, 30.01.17 20:33, Badrish Adiga H R (badrish.adig...@gmail.com) wrote:

> Hi,
> 
> I want to use socket activated ssh daemon. However currently this is
> working file only for default namespace.
> 
> I just want to make systemd to listen on a tcp port number(22 for ssh)
> on all the namespaces and to launch sshd@.service on the corresponding
> namespace. Can you help me in this regard, if there is already a
> solution to this?

This is currently not supported. However, adding this would be OK I
figure. This would require two changes however:

a) add NetworkNamespace= or so as a new service unit file setting that
   takes a a path to a namespace handle file.

b) teach .socket units namespace support, honouring JoinsNamespaceOf=
   as well as as supporting NetworkNamespace directly.

It's not trivial to add that, but patches would be welcome.

Lennart

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

Re: [systemd-devel] .device not creating in systemd

[Lennart Poettering]

On Tue, 31.01.17 15:46, Arun Kumar (arunkumar281...@gmail.com) wrote:

> Hi all,
> 
> Previously i used systemd version 206 and kernel version 3.10.17.
> 
> Now I updated kernel version to 4.1.15 and systemd version to 229.
> 
> I'm using yocto for build.
> 
> I was mounting few devices from systemd using .mount service file. In that
> I'm using requires and wants as .device.
> 
> After updating systemd with latest version there is no .device creating. I
> verified with bootchart and also with
> 
> # systemctl list-units
> command.
> The devices are not shown. Please suggest ideas as I want to use the mount
> from systemd.


Well, what does "udevadm info" say for the device? Do you have the
"systemd" tag on the udev device? 

Lennart

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

Re: [systemd-devel] redirect multiple local ports to corresponding remote IPs / ports?

[Lennart Poettering]

On Mon, 06.02.17 17:41, Patrick Schleizer (patrick-mailingli...@whonix.org) 
wrote:

> systemd directive ListenStream and systemd-socket-proxyd is really useful.
> 
> Let's say I want to redirect...
> 
> ListenStream=80
> ListenStream=81
> etc.
> 
> ExecStart=/usr/lib/systemd/systemd-socket-proxyd
> 
> Is there during ExecStart some way to get the ListenStream port? I.e.
> 
> ExecStart=/usr/lib/systemd/systemd-socket-proxyd 10.152.152.10:${PORT}
> 
> I mean, if
> - ListenStream=80 -> ExecStart=/usr/lib/systemd/systemd-socket-proxyd
> 10.152.152.10:80
> - ListenStream=81 -> ExecStart=/usr/lib/systemd/systemd-socket-proxyd
> 10.152.152.10:81
> etc.
> 
> Or can there be a wrapper that has access to the ListenStream port number?
> 
> If you are wondering what I am trying to do... I am trying to port
> anon-ws-disable-stacked-tor from loads of mostly idle socat listeners to
> systemd socket activation. Ideally, rather elegantly without one systemd
> unit file per port redirection. [1] [2] [3] [4]

This is not supported. But if you send a PR that makes it possible to
derive the port nr for the destination from the port nr of the
listening socket, then that'd certainly be welcome and we'd merge it
after review.

Lennart

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

[systemd-devel] redirect multiple local ports to corresponding remote IPs / ports?

[Patrick Schleizer]

systemd directive ListenStream and systemd-socket-proxyd is really useful.

Let's say I want to redirect...

ListenStream=80
ListenStream=81
etc.

ExecStart=/usr/lib/systemd/systemd-socket-proxyd

Is there during ExecStart some way to get the ListenStream port? I.e.

ExecStart=/usr/lib/systemd/systemd-socket-proxyd 10.152.152.10:${PORT}

I mean, if
- ListenStream=80 -> ExecStart=/usr/lib/systemd/systemd-socket-proxyd
10.152.152.10:80
- ListenStream=81 -> ExecStart=/usr/lib/systemd/systemd-socket-proxyd
10.152.152.10:81
etc.

Or can there be a wrapper that has access to the ListenStream port number?

If you are wondering what I am trying to do... I am trying to port
anon-ws-disable-stacked-tor from loads of mostly idle socat listeners to
systemd socket activation. Ideally, rather elegantly without one systemd
unit file per port redirection. [1] [2] [3] [4]

Best regards,
Patrick

[1]
https://github.com/Whonix/anon-ws-disable-stacked-tor/blob/master/etc/anon-ws-disable-stacked-tor.d/30_anon-dist.conf
[2]
https://github.com/Whonix/anon-ws-disable-stacked-tor/blob/master/lib/systemd/system/anon-ws-disable-stacked-tor.service
[3]
https://github.com/Whonix/anon-ws-disable-stacked-tor/blob/master/usr/lib/anon-ws-disable-stacked-tor/socat-unix-sockets
[4] https://github.com/Whonix/anon-ws-disable-stacked-tor
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Is sd_journal_send non-blocking?

[Lennart Poettering]

On Mon, 06.02.17 13:25, Florian Weimer (fwei...@redhat.com) wrote:

> > The socket we use is blocking, but we try to increase the socket
> > buffer to 8M, to move the point where we start to block out late. But
> > that only works with sufficient privileges.
> 
> The sender buffer size is currently a limit on the datagram size.  The data
> goes straight into the receiver's buffer, so it doesn't have any impact on
> blocking behavior.

Well, the receiver buffer islarge anyway, it's journald on the other
side, and that is privileged.

> > So yes, we are always blocking, we don't throw data away.
> 
> Sure.  I was wondering if indefinite blocking is considered a critical
> service failure and if there is a watchdog which would catch a stuck journal
> daemon.

The watchdog logic is enabled for journald, and it's at 3min by
default, if that's what are you asking?

> > I'd be willing to take a patch however, that adds a call
> > sd_journal_set_block_timeout() or so, that takes a time value we pass
> > to SO_SNDTIMEO for the logging socket. This would permit clients to
> > precisely control how long they want us to wait before we give up. And
> > in the case where a zero timeout is set we'd instead set O_NONBLOCK,
> > thus making logging entirely non-blocking.
> 
> This would help with discarding data.  It would not help those who want to
> integrate logging into an event loop.  Which is probably bad idea anyway,
> but I'm not quite sure yet what the purpose of non-blocking logging is.
> Perhaps there is a desire to apply some back-pressure to reduce the rate at
> which logging messages are generated.  But in general, this merely
> introduces deadlocks.

We could expose the logging socket too, so that people could poll() on
it. But uh, I seriously doubt this is actually a good idea...

Lennart

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

Re: [systemd-devel] Is sd_journal_send non-blocking?

[Florian Weimer]

On 02/06/2017 12:36 PM, Lennart Poettering wrote:

On Mon, 06.02.17 11:12, Florian Weimer (fwei...@redhat.com) wrote:


The manual page I've got does not say it is, but the implementation does not
wait for acknowledgment from the journal.  The implementation does not block
explicitly, but I think the sendmsg call can block until the receiver queue
is empty.

The background for this question is that we have a feature request for a
non-blocking logging interface.  I wonder if the journal fits this
requirement.

I assume that with “non-blocking”, the feature request submitter means that
the function does not block indefinitely, say due to a service process
outage.  Memory allocations can take a fairly long time as well (due to
paging), but I think that doesn't count here.


The socket we use is blocking, but we try to increase the socket
buffer to 8M, to move the point where we start to block out late. But
that only works with sufficient privileges.


The sender buffer size is currently a limit on the datagram size.  The 
data goes straight into the receiver's buffer, so it doesn't have any 
impact on blocking behavior.



So yes, we are always blocking, we don't throw data away.


Sure.  I was wondering if indefinite blocking is considered a critical 
service failure and if there is a watchdog which would catch a stuck 
journal daemon.


(Hanging syslog servers are apparently a fairly common problem, and this 
is where the RFE originally came from.)



I'd be willing to take a patch however, that adds a call
sd_journal_set_block_timeout() or so, that takes a time value we pass
to SO_SNDTIMEO for the logging socket. This would permit clients to
precisely control how long they want us to wait before we give up. And
in the case where a zero timeout is set we'd instead set O_NONBLOCK,
thus making logging entirely non-blocking.


This would help with discarding data.  It would not help those who want 
to integrate logging into an event loop.  Which is probably bad idea 
anyway, but I'm not quite sure yet what the purpose of non-blocking 
logging is.  Perhaps there is a desire to apply some back-pressure to 
reduce the rate at which logging messages are generated.  But in 
general, this merely introduces deadlocks.


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

Re: [systemd-devel] Is sd_journal_send non-blocking?

[Lennart Poettering]

On Mon, 06.02.17 11:12, Florian Weimer (fwei...@redhat.com) wrote:

> The manual page I've got does not say it is, but the implementation does not
> wait for acknowledgment from the journal.  The implementation does not block
> explicitly, but I think the sendmsg call can block until the receiver queue
> is empty.
> 
> The background for this question is that we have a feature request for a
> non-blocking logging interface.  I wonder if the journal fits this
> requirement.
> 
> I assume that with “non-blocking”, the feature request submitter means that
> the function does not block indefinitely, say due to a service process
> outage.  Memory allocations can take a fairly long time as well (due to
> paging), but I think that doesn't count here.

The socket we use is blocking, but we try to increase the socket
buffer to 8M, to move the point where we start to block out late. But
that only works with sufficient privileges.

So yes, we are always blocking, we don't throw data away.

I'd be willing to take a patch however, that adds a call
sd_journal_set_block_timeout() or so, that takes a time value we pass
to SO_SNDTIMEO for the logging socket. This would permit clients to
precisely control how long they want us to wait before we give up. And
in the case where a zero timeout is set we'd instead set O_NONBLOCK,
thus making logging entirely non-blocking.

But of course, you can't have it both. Pick one of "don't lose
messages" and "never block". Right now we always opt for the former,
with such a function call you could give that up and opt for the
latter.

Lennart

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

[systemd-devel] Is sd_journal_send non-blocking?

[Florian Weimer]

The manual page I've got does not say it is, but the implementation does 
not wait for acknowledgment from the journal.  The implementation does 
not block explicitly, but I think the sendmsg call can block until the 
receiver queue is empty.


The background for this question is that we have a feature request for a 
non-blocking logging interface.  I wonder if the journal fits this 
requirement.


I assume that with “non-blocking”, the feature request submitter means 
that the function does not block indefinitely, say due to a service 
process outage.  Memory allocations can take a fairly long time as well 
(due to paging), but I think that doesn't count here.


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