On Thu, Jan 16, 2014 at 11:19:08AM +0100, Djalal Harouni wrote:
On Thu, Jan 16, 2014 at 06:01:58AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
Indeed, in a container (without your patches), sessions remain in
closing state. But with your patches, systemd --user instance is
started and killed
Currently the user and session states are not stable:
1) session state:
To get the session state the function session_get_state() is used.
Opening state:
At login the D-Bus CreateSession() method will call session_start()
which calls user_start() and session_start_scope() to queue
To get the state of the session, the session_get_state() is used.
This function will check if the session-scope_job is set then it will
automatically return SESSION_OPENING. This is buggy in the context of
session closing:
At logout or D-Bus TerminateSession() fifo_fd is removed:
=
To get the state of the user, the user_get_state() is used.
This function will check if the user-slice_job or the user-service_job
are set then it will automatically return USER_OPENING. This is buggy
in the context of user closing:
At logout or D-Bus TerminateUser() calls user_stop()
user_stop()
'Twas brillig, and Djalal Harouni at 20/01/14 12:18 did gyre and gimble:
Hi Coling,
Coling please I've some questions regarding what you have posted, see
below.
I'm trying to debug another bug in logind logic:
http://lists.freedesktop.org/archives/systemd-devel/2014-January/015968.html
'Twas brillig, and Hans de Goede at 21/01/14 14:38 did gyre and gimble:
Hi,
On 01/20/2014 10:54 AM, Colin Guthrie wrote:
'Twas brillig, and Hans de Goede at 20/01/14 08:42 did gyre and gimble:
Hi,
For some reason after I've built the Xorg xserver from git, and then
login
through gdm (on
'Twas brillig, and Djalal Harouni at 22/01/14 09:24 did gyre and gimble:
On Thu, Jan 16, 2014 at 11:19:08AM +0100, Djalal Harouni wrote:
On Thu, Jan 16, 2014 at 06:01:58AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
Indeed, in a container (without your patches), sessions remain in
closing state.
From: Elia Pinto devzero2...@rpm5.org
The cppcheck target was introduced by commit
16f4efb4150c65e3c61adaa8ea512489de49f532
build-sys: add cppcheck target. But it is preferable to use a make phony
target
for it, as this patch does.
There are two general reasons to use a phony target: to avoid
On Sun, Jan 19, 2014 at 5:59 AM, Kay Sievers k...@vrfy.org wrote:
On Fri, Jan 17, 2014 at 12:18 PM, Ylinen, Mikko mikko.yli...@intel.com
wrote:
Could we first try to optimize the BMP loader? Also, could you share
your test image so I can have a look?
We've simply used the web page
Hi Mikko,
On Wed, Jan 22, 2014 at 12:42 PM, Ylinen, Mikko mikko.yli...@intel.com wrote:
On Sun, Jan 19, 2014 at 5:59 AM, Kay Sievers k...@vrfy.org wrote:
On Fri, Jan 17, 2014 at 12:18 PM, Ylinen, Mikko mikko.yli...@intel.com
wrote:
Could we first try to optimize the BMP loader? Also,
On Wed, Jan 22, 2014 at 12:42 PM, Ylinen, Mikko mikko.yli...@intel.com wrote:
I verified the numbers and used test/splash.bmp as the source image.
Looks like test/splash.bmp only adds 10ms more compared with BGRX.
My original BMP is 24bit, no alpha. As far as I can tell this is the same
as
On Wed, Jan 22, 2014 at 1:53 PM, Kay Sievers k...@vrfy.org wrote:
On Wed, Jan 22, 2014 at 12:42 PM, Ylinen, Mikko mikko.yli...@intel.com
wrote:
I verified the numbers and used test/splash.bmp as the source image.
Looks like test/splash.bmp only adds 10ms more compared with BGRX.
My
Hi Tom,
Making RTM_GETLINK and RTM_SETLINK asynchronously is causing
RTM_SETLINK to remove the nic's functionality. In my case, I am
loosing IFF_MULTICAST after networkd sets the interface up.
I am not sure if 5d4795f37229 can solve the problem but the only
documentation I found was stating
Hi Umut,
On Wed, Jan 22, 2014 at 7:03 PM, Umut Tezduyar u...@tezduyar.com wrote:
Making RTM_GETLINK and RTM_SETLINK asynchronously is causing
RTM_SETLINK to remove the nic's functionality. In my case, I am
loosing IFF_MULTICAST after networkd sets the interface up.
I am not sure if
On Wed, Jan 22, 2014 at 7:34 PM, Tom Gundersen t...@jklm.no wrote:
Hi Umut,
On Wed, Jan 22, 2014 at 7:03 PM, Umut Tezduyar u...@tezduyar.com wrote:
Making RTM_GETLINK and RTM_SETLINK asynchronously is causing
RTM_SETLINK to remove the nic's functionality. In my case, I am
loosing
Hi Umut,
Making RTM_GETLINK and RTM_SETLINK asynchronously is causing
RTM_SETLINK to remove the nic's functionality. In my case, I am
loosing IFF_MULTICAST after networkd sets the interface up.
I am not sure if 5d4795f37229 can solve the problem but the only
documentation I found was
Hi Marcel, Tom,
Thanks for the tips. Tom, I will try the git and let you know if it
doesn't work but from the kernel code, it seems it should work fine.
Thanks,
Umut
On Wed, Jan 22, 2014 at 8:08 PM, Marcel Holtmann mar...@holtmann.org wrote:
Hi Umut,
Making RTM_GETLINK and RTM_SETLINK
---
Hi,
This patch ports the syscall filter to libseccomp. It can be disable with
--disable-seccomp and is enabled by default if libseccomp is present.
Maybe I should add a warning when parsing SyscallFilter in a .service
if seccomp has been disabled ?
Now the SyscallFilter property is a
---
test/TEST-04-SECCOMP/Makefile | 1 +
test/TEST-04-SECCOMP/test-seccomp.sh| 11
test/TEST-04-SECCOMP/test.sh| 79 +
test/TEST-04-SECCOMP/will-fail.service | 6 +++
test/TEST-04-SECCOMP/will-not-fail.service | 6 +++
19 matches
Mail list logo
