Re: [systemd-devel] dbus activation service path
Hello Simon, Thanks for the response. I created https://github.com/bus1/dbus-broker/issues/219 On Mon, Jan 27, 2020 at 10:28 PM Simon McVittie wrote: > > On Fri, 24 Jan 2020 at 23:27:20 +0200, Damian Ivanov wrote: > > I also have a question about dbus activation. > > Is there an environment variable or something to tell systemd/dbus-broker > > > > to look in a specific path for dbus .service files? > > The D-Bus Specification[1] says: > > On Unix systems, the session bus should search for .service files in > $XDG_DATA_DIRS/dbus-1/services as defined by the XDG Base Directory > Specification. Implementations may also search additional locations, > with a higher or lower priority than the XDG directories. > > so you should set the environment variables XDG_DATA_HOME and/or > XDG_DATA_DIRS, the same way you set those variables to influence the > search path for .desktop files. See [2] for more information. > > If a piece of software that reads session service definition files does > not do this, please report that as a bug in that piece of software, using > its bug tracking system. In particular, if you believe dbus-broker has > a bug in this area, reporting it in flatpak's bug tracker is unlikely > to get it seen or fixed by dbus-broker developers. > > smcv > > [1] https://dbus.freedesktop.org/doc/dbus-specification.html > [2] > https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] The meaning of CanMultiSession=no on non-seat0
Hi Sorry if this is the wrong place for this. I can't seem to find a system-user mailing list for this purpose on freedesktop. So I am curious about what CanMultiSession=no means, as I am able to start a Weston session on a secondary seat (eg seat1 if I set up the hardware with udev or seat-pci-pci-_xx_xx_x if I use pci-bridge-seat devices on QEMU. These seats, since they don't have TTYs I guess say CanMultiSession=no which is my understanding, however, I can start a second instance of Weston, and switch in between them fine, and Weston seems to respond to the sessions switching, so I am not quite sure what is missing? Is it something else related to security? Or the kernel? Because as far as I can tell, I can start multiple sessions on these seats. Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: show journalctl while stopping?
On Fri, Jan 24, 2020 at 10:00 AM Michael Biebl wrote: > > Am Fr., 24. Jan. 2020 um 09:45 Uhr schrieb Ulrich Windl > : > > > Similarly: Before bashing the proposal, why not think about an option that > > will enable that feature? Like "--verbose", "--monitor", > > "--whatever-you-like"... > > There you go > https://github.com/systemd/systemd/blob/master/TODO#L891 Were referring to this line: - Add a verbose mode to "systemctl start" and friends that explains what is being done or not done 923 in that case, +1 from me! If it could show things as they are being done like the output of the ExecStop command as it runs, that would be grand. Thanks all. -Roger- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Dynamic .timer scheduling
Is there a best practice for scheduling .timers based on what happened in a previous run? Pseudocode: while( true ) : delta = runService(); sleep( delta ); I can think of … 1) run the job frequently, but skip the bulk of its execution most of the time (e.g. decrementing a counter saved somewhere) 2) have the job modify the .timer file at the end of each run (sounds … not so great) There isn’t anything systemd “native” for that, right? Thanks, Johannes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Conditional dependency
On Mo, 27.01.20 12:33, prashantkumar dhotre (prashantkumardho...@gmail.com) wrote: > Hi, > Is there a way to specify conditional dependency in service files ? > My use case is : I have a include file my.include that contains > 'After=core.service' among other things. Note that we explicitly do not support ".include" expressions anymore, and have not supported them in a long time. Yes, the code still parses them, but don't use that. Use drop-ins for unit files instead. > I have services A,B,C and X. As of now , all include my.include. > Now my requirement is - I want services A,B and C to be dependent on > core.service but X service should not depend on core.service.one solution > i thought is - > Instead of include my.include in all 4 services, I can create 2 > separate include files and include appropriate files in those services. > Is there any other better way ? First: Do not use include files. Use drop-ins, i.e. foor X.service add an extension drop-in X.service.d/foobar.conf or so. If you want to extend your units with different contents depending on the unit then you probably should use different drop-ins for them. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SSL_connect fails on systemd socket
On Tue, Jan 28, 2020 at 4:23 PM Tiwari, Hari Sahaya < hari-sahaya.tiw...@hpe.com> wrote: > Hi, > > > > I am trying to implement a client server program over SSL through systemd. > > Here I have a TCP systemd socket (listening on a predefined port) and its > associated service. > > > > systemd socket file:- > > # cat /usr/lib/systemd/system/test_ssl.socket > > [Unit] > > Description=Test socket > > > > [Socket] > > ListenStream=2000 > > Accept=true > > MaxConnections=900 > > > > [Install] > > WantedBy=sockets.target > > > > systemd service file:- > > # cat /usr/lib/systemd/system/test_ssl@.service > > [Unit] > > Description= Test Service > > Requires=test_ssl.socket > > > > [Service] > > ExecStart=/home/SSL/server > > StandardInput=socket > > KillMode=process > > > > [Install] > > WantedBy=multi-user.target > > > > The service file invoke the binary /home/SSL/server. > > > > Here is it a very simple client server program, where > > 1. Server binds and listens on a port number. > You need to remove this part if you want to use socket activation. The whole point of .socket units here is that systemd binds to the socket and passes the fd over to your service. If your service ignores the received fd and tries to create its own socket, it will never be able to receive the connections. By default, the service would receive the sockets as fd#3 and ahove (see https://www.freedesktop.org/software/systemd/man/sd_listen_fds.html for documentation), but because you use StandardInput=socket, it will receive the socket as fd#1. > 2. Client first connects to server with normal connect (server will > do accept) > Your .socket specifies Accept=true, so you should remove this part as well: the option means that systemd itself will accept the connection and only hand your server the accepted socket. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] SSL_connect fails on systemd socket
Hi, I am trying to implement a client server program over SSL through systemd. Here I have a TCP systemd socket (listening on a predefined port) and its associated service. systemd socket file:- # cat /usr/lib/systemd/system/test_ssl.socket [Unit] Description=Test socket [Socket] ListenStream=2000 Accept=true MaxConnections=900 [Install] WantedBy=sockets.target systemd service file:- # cat /usr/lib/systemd/system/test_ssl@.service [Unit] Description= Test Service Requires=test_ssl.socket [Service] ExecStart=/home/SSL/server StandardInput=socket KillMode=process [Install] WantedBy=multi-user.target The service file invoke the binary /home/SSL/server. Here is it a very simple client server program, where 1. Server binds and listens on a port number. 2. Client first connects to server with normal connect (server will do accept) 3. Once it gets the fd, client does the SSL_connect over same connection. (server will do SSL_accept) 4. After that it will be SSL_read & SSL_write. Once, I start the systemd socket I can see the systemd starts listening on port 2000. # systemctl start test_ssl.socket # netstat -an | grep 2000 tcp6 0 0 :::2000 :::*LISTEN Post than when executing client, SSL_conect fails. # ./client localhost 2000 OpenConnection succedeed. << normal connect succeeds. SSL_connect failed. 140691172779952:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:365: Here client is able to do normal connect, post that SSL_connect fails. This client server program works well outside of systemd. Do I need to add some extra steps to get this working? Any help or reference would be appreciated. Thanks & Regards, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] detect_container() for recent(?) docker
On Tue, 28 Jan 2020 15:28:08 +0300 "Matwey V. Kornilov" wrote: > вт, 28 янв. 2020 г. в 15:25, Lennart Poettering > : > > We document the requirements and expectations to run systemd in > > containers very explicitly here: > > > > https://systemd.io/CONTAINER_INTERFACE > > If I could google this page, it would save lot of my time. Thanks a > lot! The order of hits in google is google's choice, of course, and not systemd. Having said that, when I google for 'systemd container interface' (without the quotes), the first hit is https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/ and the first thing that says is 'This page moved to https://systemd.io/CONTAINER_INTERFACE ' ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] detect_container() for recent(?) docker
вт, 28 янв. 2020 г. в 15:25, Lennart Poettering : > > On Di, 28.01.20 15:07, Matwey V. Kornilov (matwey.korni...@gmail.com) wrote: > > > Thanks for reply! I've just wanted to let you know about this issue > > after spending couple hours trying to understand why my container > > works on the one host and don't work on another one. > > I think there are couple things which can be done here. First, it > > would be great to modify the comment as proposed in PR 8200. If I knew > > that this test is fuzzy, I would not write this mail. > > Second, I didn't know about $container env until I read systemd > > sources. There are a lot of fragmental information about running > > systemd in docker in Internet, it would be great to have official > > systemd-point-of-view on this topic. > > We document the requirements and expectations to run systemd in > containers very explicitly here: > > https://systemd.io/CONTAINER_INTERFACE If I could google this page, it would save lot of my time. Thanks a lot! > > The intention of that documentation is of course that container > managers can make systemd payloads just work. To my knowledge most > container managers implemented the bits necessary for that, but Docker > people are not interested in this. There's little we can do about > that. > > I am sorry you picked the one container implementation who's not > interested in playing with the others, but there's nothing much we can > do about that. > > Lennart > > -- > Lennart Poettering, Berlin -- With best regards, Matwey V. Kornilov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] detect_container() for recent(?) docker
On Di, 28.01.20 15:07, Matwey V. Kornilov (matwey.korni...@gmail.com) wrote: > Thanks for reply! I've just wanted to let you know about this issue > after spending couple hours trying to understand why my container > works on the one host and don't work on another one. > I think there are couple things which can be done here. First, it > would be great to modify the comment as proposed in PR 8200. If I knew > that this test is fuzzy, I would not write this mail. > Second, I didn't know about $container env until I read systemd > sources. There are a lot of fragmental information about running > systemd in docker in Internet, it would be great to have official > systemd-point-of-view on this topic. We document the requirements and expectations to run systemd in containers very explicitly here: https://systemd.io/CONTAINER_INTERFACE The intention of that documentation is of course that container managers can make systemd payloads just work. To my knowledge most container managers implemented the bits necessary for that, but Docker people are not interested in this. There's little we can do about that. I am sorry you picked the one container implementation who's not interested in playing with the others, but there's nothing much we can do about that. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] detect_container() for recent(?) docker
вт, 28 янв. 2020 г. в 11:36, Lennart Poettering :
>
> On So, 26.01.20 11:55, Matwey V. Kornilov (matwey.korni...@gmail.com) wrote:
>
> > Hello,
> >
> > I've just found that an assumption used inside detect_container() is
> > not always true, and that leads to virtualization misdetection.
> > Namely, I am running systemd inside docker (19.03.5) container on
> > ubuntu (18.04.2 kernel version is 4.15.0-45-generic).
> >
> > /* Interestingly /proc/1/sched actually shows the host's PID
> > for what we see as PID 1. If the PID
> > * shown there is not 1, we know we are in a PID namespace and
> > hence a container. */
> > check_sched:
> > r = read_one_line_file("/proc/1/sched", );
> >
> > However, I see the following when reading this file in the container:
> >
> > 64813fe8f025:/ # cat /proc/1/sched
> > bash (1, #threads: 1)
>
> Yes, this is known, and to our knowledge not really fixable, as
> there's no nice way to detect containers entirely generically these
> days (or more specifically: detect whether we are in a pidns that is
> not the main one).
>
> Also see:
>
> https://github.com/systemd/systemd/pull/8200
>
> > Unfortunately, this leads to virtualization misdetection on systemd
> > startup (docker host runs inside kvm):
>
> So, docker is the only container engine to my knowledge that refuses
> to play nice by default and is thus unwilling to implement the
> $container env var by default. To make the container env detectable
> you hence have to set the env var manually in your containers.
>
> Sorry for that, but there's nothing we can do about this. The kernel took
> the only somewhat generic mechanism to detect containers away from us
> and the Docker people aren't willing to make their stuff detectable,
> hence there's nothing we can do.
>
Hi,
Thanks for reply! I've just wanted to let you know about this issue
after spending couple hours trying to understand why my container
works on the one host and don't work on another one.
I think there are couple things which can be done here. First, it
would be great to modify the comment as proposed in PR 8200. If I knew
that this test is fuzzy, I would not write this mail.
Second, I didn't know about $container env until I read systemd
sources. There are a lot of fragmental information about running
systemd in docker in Internet, it would be great to have official
systemd-point-of-view on this topic.
> Lennart
>
> --
> Lennart Poettering, Berlin
--
With best regards,
Matwey V. Kornilov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] detect_container() for recent(?) docker
On So, 26.01.20 11:55, Matwey V. Kornilov (matwey.korni...@gmail.com) wrote:
> Hello,
>
> I've just found that an assumption used inside detect_container() is
> not always true, and that leads to virtualization misdetection.
> Namely, I am running systemd inside docker (19.03.5) container on
> ubuntu (18.04.2 kernel version is 4.15.0-45-generic).
>
> /* Interestingly /proc/1/sched actually shows the host's PID
> for what we see as PID 1. If the PID
> * shown there is not 1, we know we are in a PID namespace and
> hence a container. */
> check_sched:
> r = read_one_line_file("/proc/1/sched", );
>
> However, I see the following when reading this file in the container:
>
> 64813fe8f025:/ # cat /proc/1/sched
> bash (1, #threads: 1)
Yes, this is known, and to our knowledge not really fixable, as
there's no nice way to detect containers entirely generically these
days (or more specifically: detect whether we are in a pidns that is
not the main one).
Also see:
https://github.com/systemd/systemd/pull/8200
> Unfortunately, this leads to virtualization misdetection on systemd
> startup (docker host runs inside kvm):
So, docker is the only container engine to my knowledge that refuses
to play nice by default and is thus unwilling to implement the
$container env var by default. To make the container env detectable
you hence have to set the env var manually in your containers.
Sorry for that, but there's nothing we can do about this. The kernel took
the only somewhat generic mechanism to detect containers away from us
and the Docker people aren't willing to make their stuff detectable,
hence there's nothing we can do.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
