Re: [systemd-devel] Stopping services started by Systemd socket

[Mantas Mikulėnas]

On Tue, Jan 23, 2018 at 3:06 AM, Liam Kelly  wrote:

> How does Systemd communicate to socket activated application that the
> connection has been closed? How can I modify my application to detect this
> event if it cannot be configured to be closed automatically?
>
>
>
> We are trying to add network support to legacy code using Systemd sockets.
> Using the 0pointer tutorials, we were able to configure a listening TCP
> port and launch an instance of the application when a TCP connection came
> in. The problem is that when the connection is closed, the service is still
> running.
>
>
>
> The systemct list-units and netstat -tuapn outputs are what you would
> expect when the connection is established
>
>
>
> systemctl list-units:
>
> myapp@5-192.168.0.75:10001-192.168.210.102:19983.service loaded
> active running   My App
>
> netstat -tuapn:
>
> tcp0  0 192.168.0.75:10001  192.168.210.102:19983
> ESTABLISHED 1/init
>
> However, once the client closes the connection, the socket is closed and
> removed, but the application is still running as a service:
>

It is no different from any other type of networked service. Whether you
opened the socket yourself, or received it from a superserver, makes no
difference.

For example, if your program uses poll(), the kernel reports POLLHUP on a
closed socket. If the program uses read() or recv(), 0 bytes indicates that
the socket is closed. If the program uses simple stdio (inetd style), it's
enough to check for EOF on reads from stdin.

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

Re: [systemd-devel] SSL handshake error from offlineimap when using systemd to initialize

[Yubin Ruan]

On Mon, Jan 22, 2018 at 01:54:36PM +0100, Lennart Poettering wrote:
> On So, 21.01.18 19:12, Yubin Ruan (ablacktsh...@gmail.com) wrote:
> 
> > Hi,
> > 
> > I use offlineimap to synchronize my emails. I want it to do a 
> > synchronization
> > at system startup so recently I add a systemd service for it. However I 
> > always
> > get error like this:
> > 
> >EOF occurred in violation of protocol (_ssl.c:590)
> 
> This suggests your network doesn't work when you invoke this.
> 
> > 1. usually (after system startup) the same service is invoked by a timer
> > and it works well so there is no problem with the script.
> > 
> > 2. I believe the network is reachable, because the system will
> > auto-connect WIFI after system startup. Maybe the initialization order 
> > is
> > not configured properly? If so please see my mail service file
> > below.
> 
> Well, this is necessarily racy: your network setup races agains your
> offlineimap invocation...

I got in the configuration file

  [Unit]
  After=network.target

Isn't this enough to get the initialization order right?

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

Re: [systemd-devel] Newer videos

[Cecil Westerhof]

2018-01-22 9:29 GMT+01:00 Michal Koutný :

>
>
> On 01/21/2018 03:21 PM, Cecil Westerhof wrote:
> > I wanted to dive deeper into systemd. So I sought videos on YouTube.
> [...]
> > But that one is 2½ years old. Is there something more recent?
> https://media.ccc.de/c/asg2017
>

​Thanks, that is quite a lot. :-D
Any tips which to start with?
​

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

Re: [systemd-devel] nspawn: where is the code for ieee80211 network adapters

[Lennart Poettering]

On Sa, 20.01.18 18:25, guenther kuenzel (mog+freedesktop@guuk.eu) wrote:

> 
> hello mailing list,
> 
> i have recently opened a bug report for systemd-nspawn with the
> topic that wireless network adapters are not handled properly by
> systemd-nspawn while LXC is able to handle wireless adapters.
> 
> https://github.com/systemd/systemd/issues/7873
> 
> the bug report got closed with the argument that wifi devices are
> not compatible with network namespaces and the problem is in the
> linux kernel.

Yes, I closed that, since that was at least was what I learnt the last
time I looked into it. If LXC can do this, as you say then we should
be able to support that too.

> so, i started to dig a little bit deeper into the matter. i have to
> point out that i am not a kernel developer or an expert in regards
> to network interfaces and my skills about c/c++ programming are very
> limited.
> 
> my observations so far, i've read the sources for LXC, libvirt, iw
> and docker, is, that there has to be a distinction between the
> handling of ethernet adapters and ieee80211 adapters. what i
> understood so far, in laymans terms, is that you have to move the
> network adapter into the namespace and not the interface. this might
> sound wired for ethernet adapters, because usually the ethernet
> adapter is also the ethernet interface. but this is not true for
> ieee80211 adapters. ieee80211 adapters can have multiple interfaces
> assigned and you can switch the interfaces of an ieee80211
> adapter. this is done to allow ieee80211 adapters to change their
> mode of operations.
> 
> i've tried to identify sutch code in the systemd repository, but
> haven't been able to find it yet. maybe someone can point me to the
> right .c files which cover ieee80211 handling? then i should be able
> to continue with my investigations why my adapter is not recognized
> by systemd-nspawn and should finally be able to raise a proper bug
> report against the kernel.

There is no ieee80211 code in nspawn. We only deal with naked network
interfaces as-is. The code for that is here:

https://github.com/systemd/systemd/blob/master/src/nspawn/nspawn-network.c#L435

To make this work we probably need to query from a wifi interface to
which low-level link iface it belongs and then migrate that instead of
the specified interface. I figure adding a patch for that wouldn't be
too hard, but somebody needs to look closely what needs to be done
there.

Anyway, I have opened the bug again. Sorry for closing it prematurely.

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] [PATCH weston] doc/systemd: system service example

[Pekka Paalanen]

On Fri, 29 Dec 2017 15:09:28 -0600
Matt Hoosier  wrote:

> Hi Lennart,
> 
> On Mon, Dec 4, 2017 at 9:11 AM, Pekka Paalanen  wrote:
> > On Fri, 1 Dec 2017 18:25:35 +0100
> > Lennart Poettering  wrote:
> >  

> >> So, as long as weston runs from a PAM enabled service (and its PAM
> >> snippet pulls in pam_systemd) all should be good and race-free: as the
> >> PAM session is set up XDG_RUNTIME_DIR will be made available and the
> >> systemd --user instance is invoked in the background.  
> >
> > This is exactly what we attempted with the User and PAMName directive,
> > and it turned out to be racy somehow.

> >> > > > > > +# Set up a full user session for the user, required by Weston.
> >> > > > > > +PAMName=login  
> >> > > > >
> >> > > > > Piggy-backing on "login" is a bad idea. "login" is a text tool, and
> >> > > > > thus the PAM rules for it usually pull in some TTY specific PAM
> >> > > > > modules. YOu shoudl really use your own PAM fragment here, and
> >> > > > > configure only the bits you need.  
> >> > > >  
> >> > >
> >> > > Oh, so could it just be that we needed something other than
> >> > > "PAMName=login"?  
> >> >
> >> > What are they key bits in the PAM configuration we must have, and are
> >> > there any often used bits we must not have to avoid the race Martyn
> >> > describes?  
> >>
> >> well, pam_systemd needs to be pulled in from it, that's the most
> >> important thing. A PAM snippet that pulls in pam_systemd means you get
> >> a session allcoated in logind, which in turn sets up XDG_RUNTIME_DIR
> >> for you.  

> 
> The approach that you and Pekka most recently put on record here:
> 
> * User=foo
> * PAMName=weston
> 
> with a /etc/pam.d/weston that just does minimal stuff (enforce the
> account exists and then execute pam_systemd.so for the session phase)
> works well for me.

Hi Matt,

that is cool. Could you share your PAM file for 'weston'? When I get to
re-spinning the example patch, I could use that instead of trying to
craft my own which I probably could not test in any reasonable time.

> One thing I can't figure out though: using PAMName= causes the service
> process's journal entries emitted by regular stdout and stderr not to
> be visible with 'journalctl -u weston.service' anymore. Only the
> messages coming internally from systemd ("Started Weston." and
> similar) show in that journal.
> 
> I've tacked in StandardOutput=journal and StandardError=journal to
> compensate for the StandardInput=tty-fail. The messages do make it
> across to journald; you can view them with 'journalctl
> /usr/bin/weston'. But somehow they're not associated with the system
> unit weston.service anymore. Does using the PAMName= directive cause
> the stdout/stderr messages to be reassigned to a user-session unit or
> something?

That was an interesting point and it's nice to see Mantas' reply
explaining what happens there. I should make a note of that as well.


Thanks,
pq


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

Re: [systemd-devel] SSL handshake error from offlineimap when using systemd to initialize

[Cristian Rodríguez]

El 21-01-2018 a las 8:12, Yubin Ruan escribió:

Hi,

I use offlineimap to synchronize my emails. I want it to do a synchronization
at system startup so recently I add a systemd service for it. However I always
get error like this:

EOF occurred in violation of protocol (_ssl.c:590)


Socket was closed but not the SSL session.. not a systemd problem..


Currently I don't know what the problem is, but:

 1. usually (after system startup) the same service is invoked by a timer
 and it works well so there is no problem with the script.


It is racing against initial network setup.. once the network settles it 
works as expected.




 2. I believe the network is reachable, because the system will
 auto-connect WIFI after system startup. Maybe the initialization order is
 not configured properly? If so please see my mail service file below.


You may want to order your services after network-online and enable the 
systemd-network-online service.. however that may still race.


I heard that to perform a SSL handshake the system have to contain some
randomness (such that some random keys can be generated),


Correct, but any of the ssl libraries in linux will inmediately return 
or terminate the process in case of a entropy failure, because such 
failure is fatal and the whole security of the ssl session is screwed.




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

Re: [systemd-devel] sd_watchdog_enabled: how to use when forking process?

[Lennart Poettering]

On Fr, 19.01.18 17:41, Simon McVittie (s...@collabora.com) wrote:

> On Fri, 19 Jan 2018 at 17:22:51 +, philip is hungry wrote:
> > however if i run the forkme function (to put process in the background) it
> > behaves as follows:
> > 
> > Jan 18 15:06:25 thinkpad waitonly[11228]: Return from forkme = 11228
> > Jan 18 15:06:25 thinkpad waitonly[11228]: Return from lockme = 0
> > Jan 18 15:06:25 thinkpad waitonly[11228]: PID to compare with watchdog_pid:
> > 11228
> 
> systemd tells your service which process it expects to be sending
> keepalives ($WATCHDOG_PID), and only accepts keepalives from that
> process.

This is not fully correct. We accept keepalives from every process
that NotifyAccess= whitelists... If not specified it will only allow
them from the service's main process, which is the same as the one
indicated in $WATCHDOG_PID, but this is not true for the general
case...

But yeah, in general Simon is right: don't fork if you don#t have
to. And if you do: use NotifyAccess= and make sure that WATCHDOG_PID
matches what you expect then.

(the reason why $WATCHDOG_PID exists is to cancel the usual
inheritance effect of env vars: if we would not set it, and you have
an app that would generically ping $NOTIFY_SOCKET if $WATCHDOG_USEC is
set, then this app called from some arbitrary child process of the
daemon might feel requested to ping PID 1 even though it was only
daemon itself that was supposed to do that...)

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] SSL handshake error from offlineimap when using systemd to initialize

[Lennart Poettering]

On So, 21.01.18 19:12, Yubin Ruan (ablacktsh...@gmail.com) wrote:

> Hi,
> 
> I use offlineimap to synchronize my emails. I want it to do a synchronization
> at system startup so recently I add a systemd service for it. However I always
> get error like this:
> 
>EOF occurred in violation of protocol (_ssl.c:590)

This suggests your network doesn't work when you invoke this.

> 1. usually (after system startup) the same service is invoked by a timer
> and it works well so there is no problem with the script.
> 
> 2. I believe the network is reachable, because the system will
> auto-connect WIFI after system startup. Maybe the initialization order is
> not configured properly? If so please see my mail service file
> below.

Well, this is necessarily racy: your network setup races agains your
offlineimap invocation...

> I heard that to perform a SSL handshake the system have to contain some
> randomness (such that some random keys can be generated), so maybe a SSL
> handshake at system startup is deemed to fail?

I doubt this is related.

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 it possible to set CPUAffinity at runtime

[Lennart Poettering]

On So, 21.01.18 17:18, Cecil Westerhof (cldwester...@gmail.com) wrote:

> I would like to change the CPUaffinity of a service at runtime. Is this
> possible?

systemd does not expose this currently, even though we'd love to. This
depends on the cpuset cgroup controller in the kernel becoming usable
however, it currently is really broken conceptually on cgroupsv1, and
on cgroupsv2 currently doesn't exist at all...

So yeah, "taskset" is the only way right now.

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] sd_watchdog_enabled: how to use when forking process?

[Jérémy Rosen]

Alternatively, NotifyAccess= in [Service allows other processes to ping 
the watchdog, but Simon is right...


forking is not needed for systemd.

On 19/01/2018 18:41, Simon McVittie wrote:

On Fri, 19 Jan 2018 at 17:22:51 +, philip is hungry wrote:

however if i run the forkme function (to put process in the background) it
behaves as follows:

Jan 18 15:06:25 thinkpad waitonly[11228]: Return from forkme = 11228
Jan 18 15:06:25 thinkpad waitonly[11228]: Return from lockme = 0
Jan 18 15:06:25 thinkpad waitonly[11228]: PID to compare with watchdog_pid:
11228

systemd tells your service which process it expects to be sending
keepalives ($WATCHDOG_PID), and only accepts keepalives from that
process. The forked child process has some other process ID, so
sd_watchdog_enabled() returns false for it.

If you want to use the watchdog, don't fork and go to the background: it's
unnecessary for systemd services. To notify systemd that your process
is ready to receive requests (which was done via the double-fork trick
in init-script-based init systems), a daemon that natively supports
systemd features can use sd_notify() and Type=notify.

If you want your service to continue to support non-systemd init systems,
you might want to add a --no-fork command-line option and make the systemd
unit's ExecStart use that option. For example, that's how it works for
dbus-daemon, which needs to continue to default to forking for
compatibility with what it does on non-Linux OSs or non-systemd init.
Or, if your service will only ever run under systemd, you can make it
not fork/background itself at all.

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


--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Newer videos

[Michal Koutný]

On 01/21/2018 03:21 PM, Cecil Westerhof wrote:
> I wanted to dive deeper into systemd. So I sought videos on YouTube. [...]
> But that one is 2½ years old. Is there something more recent?
https://media.ccc.de/c/asg2017

Cheers,
Michal



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

Re: [systemd-devel] Newer videos

[Mantas Mikulėnas]

On Mon, Jan 22, 2018 at 9:31 AM, guenther kuenzel <
mog+freedesktop@guuk.eu> wrote:

>
> if this is true, then the distribution is actually forced to move it to be
> compliant with FHS3. which is also a good thing, because /usr might not be
> available during boot time.
>

/usr is always available during boot time, because we require the initramfs
to pre-mount it. Various distros have the same requirement even for SysV
boot, e.g. Gentoo [1].

[1]:
https://www.gentoo.org/support/news-items/2013-09-27-initramfs-required.html


> https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
>
> /lib Libraries essential for the binaries in /bin and /sbin.
>
> /usr/lib Libraries for the binaries in /usr/bin and /usr/sbin.
>
> which systemd
> /bin/systemd
>

$ ls -l /bin
lrwxrwxrwx 1 root root 7 Jan  5 21:17 /bin -> usr/bin/

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