On Thu, Oct 3, 2013 at 5:27 AM, Brandon Philips wrote:
> Hello-
>
> While writing against the dbus bindings I found one missing feature:
> signals from org.freedesktop.systemd1.Manager on unit "ActiveState"
> changes.
>
> I can do this today by polling ListUnits but I would rather not have
> my pr
В Tue, 1 Oct 2013 04:34:36 +0200
Lennart Poettering пишет:
> On Thu, 26.09.13 09:41, Andrey Borzenkov ([email protected]) wrote:
>
> > I'm still observing timeouts stopping [email protected] on shutdown. It
> > appears to be some race condition, because enabling debugging of either
> > main syste
Hello-
While writing against the dbus bindings I found one missing feature:
signals from org.freedesktop.systemd1.Manager on unit "ActiveState"
changes.
I can do this today by polling ListUnits but I would rather not have
my process doing this.
There are two possible APIs:
1. Distinct signal pe
On Wed, Oct 2, 2013 at 10:20 PM, Colin Guthrie wrote:
> Hi,
>
> I've googled around a bit here, but figured asking the bright minds here
> might be a good call. I know it's a bit OT, so feel free to ignore :)
>
> I'm trying to switch more of our stuff to polkit from usermode
> consolehelper (I thi
Hi,
I've googled around a bit here, but figured asking the bright minds here
might be a good call. I know it's a bit OT, so feel free to ignore :)
I'm trying to switch more of our stuff to polkit from usermode
consolehelper (I think fedora did similar a while back) and have had
only one problem s
On Wed, Oct 02, 2013 at 02:42:55AM -0700, David Strauss wrote:
> On Wed, Oct 2, 2013 at 2:04 AM, Manuel Reimer
> wrote:
> > Another option seems to be to store a timestamp in memory and use --since.
> > Maybe this is even more error proof as a cursor could maybe get invalid if
> > the log really e
On Tue, Oct 01, 2013 at 11:30:17PM -0700, David Strauss wrote:
> David Fisher has kindly informed me that high-level socket activation
> support is now available for Haskell developers!
>
> http://hackage.haskell.org/package/socket-activation
I put this link on systemd homepage.
Zbyszek
_
Allows the systemd --system process to change its current
SMACK label to a predefined custom label (usually "system")
at boot time.
This is needed to have a few system-generated folders and
sockets automatically be created with the right SMACK
label. Without that, processes either cannot communica
Once systemd itself is running in a security domain for SMACK,
it will fail to start countless tasks due to missing privileges
for mounted and created directory structures. For /run and shm
specifically, we grant all tasks access.
These 2 mounts are allowed to fail, which will happen if the
system
On Tue, Oct 1, 2013 at 4:42 PM, Lennart Poettering
wrote:
> On Tue, 01.10.13 16:11, Auke Kok ([email protected]) wrote:
>
>> index 1434dea..d7b8dce 100644
>> --- a/src/core/smack-setup.c
>> +++ b/src/core/smack-setup.c
>> @@ -36,6 +36,7 @@
>> #include "macro.h"
>> #include "smack-setup.h"
On Tue, Oct 1, 2013 at 4:40 PM, Lennart Poettering
wrote:
> On Tue, 01.10.13 16:11, Auke Kok ([email protected]) wrote:
>
>> Once system itself is running in a security domain for SMACK,
>> it will fail to start countless tasks due to missing privileges
>> for mounted and created directory
Hi,
This message is only for archiving purposes. I have noticed that
journal is not persisting on jffs2 file system and my guess is it is
due to missing mmap support of jffs2.
I don't have an easy workaround other than:
a) Making journal forwarding logs to a home grown daemon that writes
message
Hi,
I haven't seen a delay on my boot but I was thinking maybe you can try
to comment out following section to see if it will make any
difference.
+if (se->state == SERVICE_RUNNING)
+socket_set_state(s, SOCKET_RUNNING);
On Wed, Oct 2, 2013 at 12:50 PM, Colin Guthrie wr
On Tue, Oct 1, 2013 at 3:51 AM, Lennart Poettering
wrote:
> On Fri, 27.09.13 11:37, Umut Tezduyar ([email protected]) wrote:
>
>> Hi,
>>
>> I have noticed that ExecStop is not being run on following service
>> with following requests:
>>
>> [Service]
>> Type=oneshot
>> RemainAfterExit=yes
>> ExecS
'Twas brillig, and Colin Guthrie at 21/09/13 11:57 did gyre and gimble:
> 'Twas brillig, and Colin Guthrie at 19/09/13 00:54 did gyre and gimble:
>> Hi,
>>
>> While I'm not 100% sure, (not done quite enough testing), but this patch
>> seems to have introduced some kind of race that results in me se
'Twas brillig, and David Strauss at 02/10/13 06:04 did gyre and gimble:
> And, of particular importance to some high-density users: unit
> ordering reworked around a hashmap that scales much better with large
> numbers of Unix socket and mount units. Initial testing shows
> daemon-reload times drop
On Wed, Oct 2, 2013 at 2:04 AM, Manuel Reimer
wrote:
> Another option seems to be to store a timestamp in memory and use --since.
> Maybe this is even more error proof as a cursor could maybe get invalid if
> the log really exceeds my 1M limit.
If your cursor's invalid, that probably means you've
David Strauss davidstrauss.net> writes:
> You can store the last cursor you had in each dump (even in memory
> somewhere) and tell journalctl to start from that the next time using
> --after-cursor=.
Another option seems to be to store a timestamp in memory and use --since.
Maybe this is even mor
On Wed, Oct 2, 2013 at 1:18 AM, Manuel Reimer
wrote:
> - I don't write to flash
Ah, yes, I misread your original post. I see now that the compression
needs to happen real-time.
> - What I want to do is to transfer the data, logged on the embedded system,
> to another host (server on the internet
David Strauss davidstrauss.net> writes:
> Instead of doing your own compressed dump to flash, how about this:
>
> (1) Enable persistence.
> (2) When you want a backup, force rotation by sending the journal SIGUSR2
> (3) Copy away the rotated journal file and delete it.
This doesn't help me.
Instead of doing your own compressed dump to flash, how about this:
(1) Enable persistence.
(2) When you want a backup, force rotation by sending the journal SIGUSR2 [1].
(3) Copy away the rotated journal file and delete it.
This would allow getting entries in a way that's compressed and never
David Strauss davidstrauss.net> writes:
> Do you really need to clear it? Presumably, the system has to meet its
> memory constraints just before you dump the logs. What is the
> advantage of freeing memory that the system has to account for,
> anyway?
Yes, that's right. Maybe I even reduce the v
On Tue, Oct 1, 2013 at 11:48 PM, Manuel Reimer
wrote:
> So long story short: How to tell journald to just forget all previously
> logged stuff? Can I safely delete anything below /run/log/journal? Will this
> really clear the log (journalctl no longer returns anything after that)?
Do you really n
23 matches
Mail list logo
