Another dbus question:
Is it expected that a UnitNew and UnitRemove are sent when I use
org.freedesktop.DBus.Properties.Get or GetAll? This also happens with
`systemctl status doesnt-exist.service`
Here is an example of what I am seeing:
https://gist.github.com/philips/6834913/raw/5bd36998829ca44
On Fri, Oct 4, 2013 at 8:57 PM, Kok, Auke-jan H
wrote:
> On Fri, Oct 4, 2013 at 9:37 AM, Toms Seisums wrote:
>> [object Object]
>
> Look at Gmail failing flat on its face... lol
>
> Aside from that, can you perhaps try this patch:
>
> --- systemd-user-sessions.service 2013-10-02 15:37:14.18133028
On 10/4/13 6:38 PM, Stephan Raue wrote:
if you need a receipt to crosscompile libcap see:
https://github.com/OpenELEC/OpenELEC.tv/blob/master/packages/devel/libcap/build
basically you must compile _makenames first with the hosttools:
make CC=$HOST_CC -C libcap _makenames
as a second step
On Fri, Oct 4, 2013 at 9:37 AM, Toms Seisums wrote:
> [object Object]
Look at Gmail failing flat on its face... lol
Aside from that, can you perhaps try this patch:
--- systemd-user-sessions.service 2013-10-02 15:37:14.181330287 -0700
+++ systemd-user-sessions.service 2013-10-04 11:53:37.02
All of those are shutdown messages, generated by:
http://freedesktop.org/wiki/Software/systemd/Debugging/#shutdowncompleteseventually
In case boot messages are needed, I'll be able to provide them on monday.
If I need to change some kernel parameters for shutdown to get more verbose
output, I'd l
В Fri, 4 Oct 2013 19:31:43 +0300
Toms Seisums пишет:
> @Andrey, the full log can be found here, the link was there before also:
> http://pastebin.com/wbr04AQw (systemd-207)
> It's quite silent about the cause for the timeout, though.
How do you generate it? It lacks any output from systemd in us
if you need a receipt to crosscompile libcap see:
https://github.com/OpenELEC/OpenELEC.tv/blob/master/packages/devel/libcap/build
basically you must compile _makenames first with the hosttools:
make CC=$HOST_CC -C libcap _makenames
as a second step you crosscompile libcap like:
make CC=$T
Next reboot after the [email protected] start/stop cycle was a quick one. It
looks as something gets messed up upon logging in. And if not resolved, the
system has problems shutting down.
On 4 October 2013 19:31, Toms Seisums wrote:
> @Andrey, the full log can be found here, the link was there bef
@Andrey, the full log can be found here, the link was there before also:
http://pastebin.com/wbr04AQw (systemd-207)
It's quite silent about the cause for the timeout, though.
I've been debugging this for three days now, and I've crystallized a little
bit of information.
1. If I boot the system an
On Fri, 04.10.13 17:12, Warpme ([email protected]) wrote:
> Hi,
> I want to build sytemd in cross-build environment.
> One from many needed dependencies is libcap which is really old and
> isn't cross-build friendly.
> It looks like libcap-ng is kind of successor and I can build this
> lib in my cross-
Hi,
I want to build sytemd in cross-build environment.
One from many needed dependencies is libcap which is really old and
isn't cross-build friendly.
It looks like libcap-ng is kind of successor and I can build this lib in
my cross-build environment.
Is there any way to build systemd with libc
On Fri, Oct 04, 2013 at 04:50:30PM +0200, Lennart Poettering wrote:
> On Fri, 04.10.13 11:00, Ramkumar Ramachandra ([email protected]) wrote:
>
> > Kernel hackers need access to the debugfs filesystem. For instance, see
> > the performance subsystem (tools/perf in the kernel tree); we should let
On Fri, 04.10.13 11:00, Ramkumar Ramachandra ([email protected]) wrote:
> Kernel hackers need access to the debugfs filesystem. For instance, see
> the performance subsystem (tools/perf in the kernel tree); we should let
> all users, not just root, run the perf tool to collect performance
> infor
On Fri, Oct 4, 2013 at 7:30 AM, Ramkumar Ramachandra wrote:
> Kernel hackers need access to the debugfs filesystem. For instance, see
> the performance subsystem (tools/perf in the kernel tree); we should let
> all users, not just root, run the perf tool to collect performance
> information about
Am 04.10.2013 13:52, schrieb Zbigniew Jędrzejewski-Szmek:
>>> Colin had the great idea that we drop mask root-fsck.service in
>> /run/systemd/system/ when we run fsck in initrd. For example, the initrd
>> generator could add a service to the initrd that creates the symlink and
>> a .d snippet that
On Fri, Oct 04, 2013 at 11:34:44AM +0200, Thomas Bächler wrote:
> Am 01.10.2013 02:58, schrieb Lennart Poettering:
> > Originally the intention was that root-fsck.service would run fsck for
> > the root device, anf [email protected] would be used for the rest. The
> > difference is mostly one about ord
Am 01.10.2013 02:58, schrieb Lennart Poettering:
> Originally the intention was that root-fsck.service would run fsck for
> the root device, anf [email protected] would be used for the rest. The
> difference is mostly one about ordering, i.e. root-fsck.service is the
> only one that is fine with the fs
Kernel hackers need access to the debugfs filesystem. For instance, see
the performance subsystem (tools/perf in the kernel tree); we should let
all users, not just root, run the perf tool to collect performance
information about their programs by default.
Cc: Lennart Poettering
Signed-off-by: Ra
18 matches
Mail list logo
