[systemd-devel] [PATCH]fopen_temporary: close fd if fail

[cee1]

-- 
Regards,

- cee1


0001-basic-util.c-fopen_temporary-close-fd-if-failed.patch
Description: Binary data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] HEADS-UP: splitting python-systemd out

[Daniel Mack]

On 07/08/2015 03:43 PM, Michael Biebl wrote:
> 2015-07-08 21:17 GMT+02:00 Zbigniew Jędrzejewski-Szmek :
>> On Tue, Jul 07, 2015 at 03:49:13PM +0200, Michael Biebl wrote:
>>> 2015-07-07 2:51 GMT+02:00 Zbigniew Jędrzejewski-Szmek :
 Comments, patches, pull requests — especially for documentation and tests —
 are very much welcome.
>>>
>>> Regarding the documentation: I failed to generate the documentation
>>> with sphinx since it didn't find the python modules.
>>> Do you have some instructions how this can be done.
>>
>> Hi,
>> this is now fixed in git.
>>
>> make sphinx-html
>> or
>> make sphinx-html PYTHON=python3.4 SPHINX_BUILD=sphinx-build-3.4
>>
>> build the docs (although the result should be indistinguishable between
>> python versions).
> 
> Thanks a lot.
> 
> FYI: https://packages.qa.debian.org/p/python-systemd.html

The PR that removes systemd-python from upstream is also merged now:

  https://github.com/systemd/systemd/commit/b9fd7bb60


Thanks,
Daniel

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

Re: [systemd-devel] HEADS-UP: splitting python-systemd out

[Michael Biebl]

2015-07-08 21:17 GMT+02:00 Zbigniew Jędrzejewski-Szmek :
> On Tue, Jul 07, 2015 at 03:49:13PM +0200, Michael Biebl wrote:
>> 2015-07-07 2:51 GMT+02:00 Zbigniew Jędrzejewski-Szmek :
>> > Comments, patches, pull requests — especially for documentation and tests —
>> > are very much welcome.
>>
>> Regarding the documentation: I failed to generate the documentation
>> with sphinx since it didn't find the python modules.
>> Do you have some instructions how this can be done.
>
> Hi,
> this is now fixed in git.
>
> make sphinx-html
> or
> make sphinx-html PYTHON=python3.4 SPHINX_BUILD=sphinx-build-3.4
>
> build the docs (although the result should be indistinguishable between
> python versions).

Thanks a lot.

FYI: https://packages.qa.debian.org/p/python-systemd.html


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] HEADS-UP: splitting python-systemd out

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 07, 2015 at 03:49:13PM +0200, Michael Biebl wrote:
> 2015-07-07 2:51 GMT+02:00 Zbigniew Jędrzejewski-Szmek :
> > Comments, patches, pull requests — especially for documentation and tests —
> > are very much welcome.
> 
> Regarding the documentation: I failed to generate the documentation
> with sphinx since it didn't find the python modules.
> Do you have some instructions how this can be done.

Hi,
this is now fixed in git.

make sphinx-html
or
make sphinx-html PYTHON=python3.4 SPHINX_BUILD=sphinx-build-3.4

build the docs (although the result should be indistinguishable between
python versions).

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

Re: [systemd-devel] sd 221 regression: login - nonexistent sessions via lightdm

[poma]

On 08.07.2015 16:39, poma wrote:
> On 08.07.2015 13:54, David Herrmann wrote:
>> Hi
>>
>> On Wed, Jul 8, 2015 at 1:29 PM, poma  wrote:
>>> Here is another case where this is still broken - LiveCD/DVD constellation.
>>> Initial log-in should work, but subsequent ones sind kaputt aber glücklich.
>>> So how to reproduce:
>>> just log-out & log-in, again.
>>>
>>> Here is a visual record:
>>> http://goo.gl/Gm4ffO
>>> Screencast/catch-a-tiger-by-the-toe.webm
>>>
>>> and here is a test compilation, so you can test it yourself:
>>> http://goo.gl/Gm4ffO
>>> ISO/Rawhide-Live-Xfce-708.iso
>>
>> I see. I assume the greeter is again started on the same VT as the
>> leaving session. If the previous session now leaves stuff behind, we
>> end up with the same issue. Does the attached patch fix this?
>>
>> (This is getting a bit convoluted.. we should really fix this properly)
>>
>> Thanks
>> David
>>
>> diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
>> index 82654ee..91cc67d 100644
>> --- a/src/login/logind-dbus.c
>> +++ b/src/login/logind-dbus.c
>> @@ -699,9 +699,12 @@ static int method_create_session(
>>   * after the user-session and want the user-session to take
>>   * over the VT. We need to support this for
>>   * backwards-compatibility, so make sure we allow new sessions
>> - * on a VT that a greeter is running on.
>> + * on a VT that a greeter is running on. Furthermore, to allow
>> + * re-logins, we have to allow a greeter to take over a used VT for
>> + * the exact same reasons.
>>   */
>> -if (vtnr > 0 &&
>> +if (class != SESSION_GREETER &&
>> +vtnr > 0 &&
>>  vtnr < m->seat0->position_count &&
>>  m->seat0->positions[vtnr] &&
>>  m->seat0->positions[vtnr]->class != SESSION_GREETER)
>>
> 
> 
> No land in sight
> no seagull in the sky
> no rum on board
> are we gonna die
> 

Translated from "Haiku",
patch does not change anything.
:)

I'll revert all the changes, actually unnecessary for lightdm scheme.
Thank you for trying to help.



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

Re: [systemd-devel] sd 221 regression: login - nonexistent sessions via lightdm

[poma]

On 08.07.2015 13:54, David Herrmann wrote:
> Hi
> 
> On Wed, Jul 8, 2015 at 1:29 PM, poma  wrote:
>> Here is another case where this is still broken - LiveCD/DVD constellation.
>> Initial log-in should work, but subsequent ones sind kaputt aber glücklich.
>> So how to reproduce:
>> just log-out & log-in, again.
>>
>> Here is a visual record:
>> http://goo.gl/Gm4ffO
>> Screencast/catch-a-tiger-by-the-toe.webm
>>
>> and here is a test compilation, so you can test it yourself:
>> http://goo.gl/Gm4ffO
>> ISO/Rawhide-Live-Xfce-708.iso
> 
> I see. I assume the greeter is again started on the same VT as the
> leaving session. If the previous session now leaves stuff behind, we
> end up with the same issue. Does the attached patch fix this?
> 
> (This is getting a bit convoluted.. we should really fix this properly)
> 
> Thanks
> David
> 
> diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
> index 82654ee..91cc67d 100644
> --- a/src/login/logind-dbus.c
> +++ b/src/login/logind-dbus.c
> @@ -699,9 +699,12 @@ static int method_create_session(
>   * after the user-session and want the user-session to take
>   * over the VT. We need to support this for
>   * backwards-compatibility, so make sure we allow new sessions
> - * on a VT that a greeter is running on.
> + * on a VT that a greeter is running on. Furthermore, to allow
> + * re-logins, we have to allow a greeter to take over a used VT for
> + * the exact same reasons.
>   */
> -if (vtnr > 0 &&
> +if (class != SESSION_GREETER &&
> +vtnr > 0 &&
>  vtnr < m->seat0->position_count &&
>  m->seat0->positions[vtnr] &&
>  m->seat0->positions[vtnr]->class != SESSION_GREETER)
> 


No land in sight
no seagull in the sky
no rum on board
are we gonna die

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

Re: [systemd-devel] Minimum required gcc version?

[Umut Tezduyar Lindskog]

For the reference, this problem is tracked @
https://github.com/systemd/systemd/issues/406

On Thu, Jun 18, 2015 at 5:34 PM, Lennart Poettering
 wrote:
> On Thu, 18.06.15 17:33, Michael Olbrich (m.olbr...@pengutronix.de) wrote:
>
>> Hi,
>>
>> On Thu, Jun 18, 2015 at 03:20:04PM +0200, Lennart Poettering wrote:
>> > On Thu, 18.06.15 14:29, Michael Olbrich (m.olbr...@pengutronix.de) wrote:
>> > > Do we have a minimum required gcc version? The README just lists gcc
>> > > without any version. However the current git fails to build with gcc-4.7:
>> > > In this version, gcc produces -Wshadow warnings for variables with the 
>> > > same
>> > > name as a defined function (e.g. 'now' in several functions in
>> > > src/core/device.c). This results in build errors because we compile with
>> > > -Werror=shadow now.
>> >
>> > Hm, yuck. I figure we could add that only for gcc versions newer than
>> > that, with a configure check...
>> >
>> > or can't you add a -Wno-shadow to CFLAGS on the configure cmdline,
>> > overriding what we set there?
>>
>> I can easily work around this issue with cc_cv_CFLAGS__Werror_shadow=no in
>> the environment for configure. I just wanted to report this in case you
>> care about gcc-4.7.
>
> Well, it's easy enough to care for it I think in this case. If you
> send me a patch that conditionalizes this in the configure script
> depending on the gcc version I'd be willing to merge it.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd 221 regression: login - nonexistent sessions via lightdm

[David Herrmann]

Hi

On Wed, Jul 8, 2015 at 1:29 PM, poma  wrote:
> Here is another case where this is still broken - LiveCD/DVD constellation.
> Initial log-in should work, but subsequent ones sind kaputt aber glücklich.
> So how to reproduce:
> just log-out & log-in, again.
>
> Here is a visual record:
> http://goo.gl/Gm4ffO
> Screencast/catch-a-tiger-by-the-toe.webm
>
> and here is a test compilation, so you can test it yourself:
> http://goo.gl/Gm4ffO
> ISO/Rawhide-Live-Xfce-708.iso

I see. I assume the greeter is again started on the same VT as the
leaving session. If the previous session now leaves stuff behind, we
end up with the same issue. Does the attached patch fix this?

(This is getting a bit convoluted.. we should really fix this properly)

Thanks
David

diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index 82654ee..91cc67d 100644
--- a/src/login/logind-dbus.c
+++ b/src/login/logind-dbus.c
@@ -699,9 +699,12 @@ static int method_create_session(
  * after the user-session and want the user-session to take
  * over the VT. We need to support this for
  * backwards-compatibility, so make sure we allow new sessions
- * on a VT that a greeter is running on.
+ * on a VT that a greeter is running on. Furthermore, to allow
+ * re-logins, we have to allow a greeter to take over a used VT for
+ * the exact same reasons.
  */
-if (vtnr > 0 &&
+if (class != SESSION_GREETER &&
+vtnr > 0 &&
 vtnr < m->seat0->position_count &&
 m->seat0->positions[vtnr] &&
 m->seat0->positions[vtnr]->class != SESSION_GREETER)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd 221 regression: login - nonexistent sessions via lightdm

[poma]

On 07.07.2015 22:49, David Herrmann wrote:
> Hi
> 
> On Tue, Jul 7, 2015 at 10:08 PM, poma  wrote:
>> On 07.07.2015 19:48, David Herrmann wrote:
>>> Hi
>>>
>>> On Tue, Jul 7, 2015 at 7:10 PM, David Herrmann  
>>> wrote:
 Hi

 On Tue, Jul 7, 2015 at 6:55 PM, Martin Pitt  wrote:
> Hey David,
>
> David Herrmann [2015-07-07 18:31 +0200]:
>>> Revert "login: re-use VT-sessions if they already exist" - commit 
>>> 0204c4b
>>> http://cgit.freedesktop.org/systemd/systemd/commit/?id=0204c4b
>>
>> Can someone elaborate what exactly lightdm does here? We really want
>> to prevent multiple sessions on the same VT. This is just nasty and
>> never made any sense. So I'm really interested why lightdm doesn't
>> kill it's manager-session before it starts the new session. Any
>> particular reason here?
>
> I'll let Robert answer with the details, but something I noticed:
>
> It's not that simple to reproduce, but sometimes it seems the lightdm
> "greeter" session (running as user lightdm, where you select user/type
> password and so on) doesn't completely terminate, but some processes
> stay around in it. Thus the greeter session stays around in state
> "Closing", and then the "real" session starts on the same VT.
>
> I asked the reporter of https://launchpad.net/bugs/1472259 to attach
> systemd-cgls, so that we can see what's running in the session.

 So it might indeed just be a race in lightdm. Hmm..
 Anyway, this patch here should also fix the issue (if it does, I'll
 commit something proper).
>>>
>>> Ok, I pushed this to -git now. Should be fixed. Can you guys verify?
>>>
>>> Thanks
>>> David
>>>
>>
>> $ loginctl list-sessions
>>SESSIONUID USER SEAT
>>  1   1001 test seat0
>> c1989 lightdm  seat0
>>
>> 2 sessions listed.
>>
>> $ loginctl show-session c1
>> Id=c1
>> Name=lightdm
>> Timestamp=Tue 2015-07-07 21:44:41 CEST
>> TimestampMonotonic=51125373
>> VTNr=1
>> Display=:0
>> Remote=no
>> Service=lightdm-greeter
>> Scope=session-c1.scope
>> Leader=1346
>> Audit=0
>> Type=x11
>> Class=greeter
>> Active=no
>> State=closing
>> IdleHint=no
>> IdleSinceHint=0
>> IdleSinceHintMonotonic=0
>>
>> $ loginctl show-session 1
>> Id=1
>> Name=test
>> Timestamp=Tue 2015-07-07 21:56:10 CEST
>> TimestampMonotonic=739928248
>> VTNr=1
>> Display=:0
>> Remote=no
>> Service=lightdm
>> Desktop=xfce
>> Scope=session-1.scope
>> Leader=1983
>> Audit=1
>> Type=x11
>> Class=user
>> Active=yes
>> State=active
>> IdleHint=no
>> IdleSinceHint=0
>> IdleSinceHintMonotonic=0
>>
>> $ rpm -q systemd lightdm lightdm-gtk
>> systemd-222-2.fc23.x86_64
>> lightdm-1.15.0-2.fc23.x86_64
>> lightdm-gtk-2.0.1-2.fc23.x86_64
>>
>> It's OK.
> 
> Much appreciated, thanks!
> 
> I'd still prefer a comment from Robert about the intended behavior.
> But that's not release critical.
> 
> Thanks
> David
> 


Here is another case where this is still broken - LiveCD/DVD constellation.
Initial log-in should work, but subsequent ones sind kaputt aber glücklich.
So how to reproduce:
just log-out & log-in, again.

Here is a visual record:
http://goo.gl/Gm4ffO
Screencast/catch-a-tiger-by-the-toe.webm

and here is a test compilation, so you can test it yourself:
http://goo.gl/Gm4ffO
ISO/Rawhide-Live-Xfce-708.iso


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

Re: [systemd-devel] from dbus , how do i find if app went down

[Pradeepa Kumar]

I am subscribing to PropertiesChanged signal and caching service and its
 substate in client side.
But i noticed that when service is started , i dont get PropertiesChanged
signal.
how can i update my local client side cache in this case ?
my goal is to let my upper layer know when app goes down (running to other
substate value)


On Mon, Jul 6, 2015 at 10:03 AM, Pradeepa Kumar 
wrote:

> Caching the unit's statet is one solution.
> But is there any alternative ?
> This seems such a basic use case , surprising why there is no easier API
> for this ?
> On research, I see that some people use JobRemoved signal and on getting
> that signal and if it 'done' they check the ActiveState to figure out if
> unit went down.
> Is this correct way?
> What is JobRemoved means?
> I am looking for simple and easier way to get notified about unit down.
> Thanks for your reply !
>
>
>
> On Fri, Jul 3, 2015 at 4:53 PM, Lennart Poettering  > wrote:
>
>> On Fri, 03.07.15 16:46, Pradeepa Kumar (cdprade...@gmail.com) wrote:
>>
>> > When you say 'Check the "state" instead '
>> > Did you mean ActiveState ?
>>
>> Yes!
>>
>> Sorry for the confusion!
>>
>> 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] [HEADSUP] systemd-222 around the corner

[Ansgar Burchardt]

Hi,

Colin Guthrie  writes:
> Bit late now, but does anyone else have the issue that calling
> "systemctl reload" will kill off any machines registered in machined.
>
> To me the problem commit is 9b420b3cfb8b93daf50e4cdbc92b05f2209ef893.
>
> machined: make sure to track machine unit states properly
>
> Can someone confirm this? (mentioned it in the "getent hosts "
> thread but no one confirmed - or denied - the problem there).

I can confirm that "systemctl daemon-reload" will make machined lose
track of containers (though the container itself keeps running) and
already opened an issue[1].

I haven't tried if reverting the commit you mentioned fixes it, but I
think the real issue might be systemd emitting UnitRemoved signals on
reload... It seems semantically incorrect to do so.

Ansgar

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

Re: [systemd-devel] [HEADSUP] systemd-222 around the corner

[Colin Guthrie]

David Herrmann wrote on 06/07/15 18:54:
> Hi
> 
> We intend to release v222 tomorrow. If anyone has open issues that
> need to be in that release, please speak up. Right now, the release
> consists almost exclusively of bug-fixes, and we want to get those
> into distributions.


Bit late now, but does anyone else have the issue that calling
"systemctl reload" will kill off any machines registered in machined.

To me the problem commit is 9b420b3cfb8b93daf50e4cdbc92b05f2209ef893.

machined: make sure to track machine unit states properly

Can someone confirm this? (mentioned it in the "getent hosts "
thread but no one confirmed - or denied - the problem there).

I'll open an issue on github if someone else can confirm in a different
setup.

Cheers!

Col

-- 

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