Op 10 apr. 2013, om 22:20 heeft "Kok, Auke-jan H"
het volgende geschreven:
> On Wed, Apr 10, 2013 at 1:12 PM, David Strauss wrote:
>> Are you sure it's not the corresponding service that really failed?
>
> actually, that's a good point, but if the "socket" unit is dead, I
> assume that system
On Wed, Apr 10, 2013 at 12:53:58PM +0200, Lukas Nykryn wrote:
> ---
> src/journal/journalctl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied 1/5, 3/5, 5/5.
Zbyszek
___
systemd-devel mailing list
[email protected]
http
On Wed, Apr 10, 2013 at 12:54:01PM +0200, Lukas Nykryn wrote:
> ---
> src/journal/journal-send.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/journal/journal-send.c b/src/journal/journal-send.c
> index 4b9109a..ae7f5e8 100644
> --- a/src/journal/journal-send.c
>
On Wed, Apr 10, 2013 at 12:53:59PM +0200, Lukas Nykryn wrote:
> ---
> src/libsystemd-id128/sd-id128.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/libsystemd-id128/sd-id128.c b/src/libsystemd-id128/sd-id128.c
> index 68c4987..a6345c8 100644
> --- a/src/libsystemd-id128/sd-id128
/usr/share/doc/systemd/README.Fedora-18
- A hacky workaround that allows udev to rename network interfaces into
kernel's ethX namespace has been re-added. This is to support users who still
rely on udev rules such as 70-persistent-net.rules generated in previous
Fedora releases to name their
bus_error and bus_error_message_or_strerror dit almost exactly the same,
so use only one of them and place it in dbus-common.
---
src/core/bus-errors.h| 13 -
src/core/load-fragment.c | 2 +-
src/core/main.c | 2 +-
src/core/path.c | 2 +-
src/core/service.c
On Wed, Apr 10, 2013 at 1:20 PM, Kok, Auke-jan H
wrote:
> actually, that's a good point, but if the "socket" unit is dead, I
> assume that systemd no longer is bind()ed to the ports...
I'd have to look at source or run some experiments for details, but I
know systemd's socket listeners can get in
On Wed, Apr 10, 2013 at 1:12 PM, David Strauss wrote:
> Are you sure it's not the corresponding service that really failed?
actually, that's a good point, but if the "socket" unit is dead, I
assume that systemd no longer is bind()ed to the ports...
Koen, can you verify that that is the case?
Au
Are you sure it's not the corresponding service that really failed?
On Wed, Apr 10, 2013 at 11:46 AM, Kok, Auke-jan H
wrote:
> On Wed, Apr 10, 2013 at 11:10 AM, Koen Kooi
> wrote:
>>
>> Op 10 apr. 2013, om 19:13 heeft Mantas Mikulėnas het
>> volgende geschreven:
>>
>>> On Wed, Apr 10, 2013 at
On Wed, Apr 10, 2013 at 11:10 AM, Koen Kooi wrote:
>
> Op 10 apr. 2013, om 19:13 heeft Mantas Mikulėnas het
> volgende geschreven:
>
>> On Wed, Apr 10, 2013 at 8:03 PM, Koen Kooi
>> wrote:
>>> Hi,
>>>
>>> I have a bit of a heisenbug where dropbear.socket will just die and needs a
>>> systemct
Op 10 apr. 2013, om 19:13 heeft Mantas Mikulėnas het
volgende geschreven:
> On Wed, Apr 10, 2013 at 8:03 PM, Koen Kooi wrote:
>> Hi,
>>
>> I have a bit of a heisenbug where dropbear.socket will just die and needs a
>> systemctl restart dropbear.socket. I can't tell why it's dying, just that
On Wed, Apr 10, 2013 at 8:03 PM, Koen Kooi wrote:
> Hi,
>
> I have a bit of a heisenbug where dropbear.socket will just die and needs a
> systemctl restart dropbear.socket. I can't tell why it's dying, just that it
> does within 3 days of uptime. After restarting it it seems to be rock solid
>
On 04/10/2013 05:03 PM, Koen Kooi wrote:
Hi,
I have a bit of a heisenbug where dropbear.socket will just die and needs a
systemctl restart dropbear.socket. I can't tell why it's dying, just that it
does within 3 days of uptime. After restarting it it seems to be rock solid
again for at least
Hi,
I have a bit of a heisenbug where dropbear.socket will just die and needs a
systemctl restart dropbear.socket. I can't tell why it's dying, just that it
does within 3 days of uptime. After restarting it it seems to be rock solid
again for at least some weeks.
The real way to fix this is to
From: Harald Hoyer
This patch adds environment variable substition for PIDFile=. To read
the environment files only once, ExecContext holds a copy of the
environment gathered.
RFE: https://bugzilla.redhat.com/show_bug.cgi?id=840260
$ cat test.service
[Unit]
Description=test
[Service]
PIDFile=$
From: Harald Hoyer
This patch adds environment variable substition for PIDFile=. To read
the environment files only once, ExecContext holds a copy of the
environment gathered.
RFE: https://bugzilla.redhat.com/show_bug.cgi?id=840260
$ cat test.service
[Unit]
Description=test
[Service]
PIDFile=$
On 03/04/13 18:48, Kok, Auke-jan H wrote:
On Wed, Apr 3, 2013 at 6:22 AM, Will Stephenson wrote:
I'm joining the flock of desktop people investigating using systemd to start a
desktop session. So far I've checked out user-session-units and have created
some more granular unit files that will
Please disregard this, I pressed ctrl-enter by mistake. Full version to
follow.
On 10/04/13 16:14, Will Stephenson wrote:
On 03/04/13 18:48, Kok, Auke-jan H wrote:
On Wed, Apr 3, 2013 at 6:22 AM, Will Stephenson
wrote:
I'm joining the flock of desktop people investigating using systemd
to st
On 03/04/13 18:48, Kok, Auke-jan H wrote:
On Wed, Apr 3, 2013 at 6:22 AM, Will Stephenson wrote:
I'm joining the flock of desktop people investigating using systemd to start a
desktop session. So far I've checked out user-session-units and have created
some more granular unit files that will
From: Harald Hoyer
RFE: https://bugzilla.redhat.com/show_bug.cgi?id=840260
$ cat test.service
[Unit]
Description=test
[Service]
PIDFile=${PIDFILE}
EnvironmentFile=/etc/test-file
ExecStart=/bin/bash -c 'sleep 1& jobs -p > $$PIDFILE; exit 0'
Type=forking
$ cat /etc/test-file
PIDFILE=/tmp/tes
Am 10.04.2013 14:29, schrieb Lennart Poettering:
> On Wed, 10.04.13 11:51, [email protected] ([email protected]) wrote:
>
>> From: Harald Hoyer
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=772073
>
> Well, at the top of exec_spawn() we actuallly already output this on
> debug level. Why do
From: Harald Hoyer
RFE: https://bugzilla.redhat.com/show_bug.cgi?id=840260
$ cat test.service
[Unit]
Description=test
[Service]
PIDFile=${PIDFILE}
EnvironmentFile=/etc/test-file
ExecStart=/bin/bash -c 'sleep 1& jobs -p > $$PIDFILE; exit 0'
Type=forking
$ cat /etc/test-file
PIDFILE=/tmp/tes
On Wed, Apr 10, 2013 at 12:34:43PM +0200, [email protected] wrote:
> From: Harald Hoyer
>
> Novice users might think, that
> $ systemctl --all
> is equal to
> $ systemctl list-unit-files
>
> https://bugzilla.redhat.com/show_bug.cgi?id=748512
Makes sense.
Zbyszek
__
On Wed, 10.04.13 11:51, [email protected] ([email protected]) wrote:
> From: Harald Hoyer
>
> https://bugzilla.redhat.com/show_bug.cgi?id=772073
Well, at the top of exec_spawn() we actuallly already output this on
debug level. Why do we need this twice?
> ---
> src/core/execute.c | 12 +++
---
src/libsystemd-bus/bus-socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libsystemd-bus/bus-socket.c b/src/libsystemd-bus/bus-socket.c
index 145f454..1a0d926 100644
--- a/src/libsystemd-bus/bus-socket.c
+++ b/src/libsystemd-bus/bus-socket.c
@@ -877,7 +877,7 @@ in
---
src/journal/journal-send.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/journal/journal-send.c b/src/journal/journal-send.c
index 4b9109a..ae7f5e8 100644
--- a/src/journal/journal-send.c
+++ b/src/journal/journal-send.c
@@ -200,7 +200,9 @@ finish:
_public_ int
---
src/tty-ask-password-agent/tty-ask-password-agent.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/tty-ask-password-agent/tty-ask-password-agent.c
b/src/tty-ask-password-agent/tty-ask-password-agent.c
index 3f5706e..1f55e32 100644
--- a/src/tty-ask-password-agent/tty-
---
src/libsystemd-id128/sd-id128.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/libsystemd-id128/sd-id128.c b/src/libsystemd-id128/sd-id128.c
index 68c4987..a6345c8 100644
--- a/src/libsystemd-id128/sd-id128.c
+++ b/src/libsystemd-id128/sd-id128.c
@@ -176,6 +176,9 @@ _public_ int sd
---
src/journal/journalctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 86895b8..002ff7c 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -1035,7 +1035,7 @@ int main(int argc, char *argv[]) {
From: Harald Hoyer
Novice users might think, that
$ systemctl --all
is equal to
$ systemctl list-unit-files
https://bugzilla.redhat.com/show_bug.cgi?id=748512
---
man/systemctl.xml | 4 +++-
src/systemctl/systemctl.c | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --g
On Wed, Apr 10, 2013 at 12:43:56PM +0300, Kevin Wilson wrote:
> Hello,
> I have a question about systemd and cgroups:
> "mount | grep cgroups" shows that only one entry has name=systemd.
> and is mounted on /sys/fs/cgroup/systemd . (see below the full output
> of "mount | grep cgroups"
>
> Is it t
Am 10.04.2013 11:49, schrieb [email protected]:
> From: Harald Hoyer
>
> https://bugzilla.redhat.com/show_bug.cgi?id=772073
> ---
> src/core/execute.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/src/core/execute.c b/src/core/execute.c
> index 5083af9..c881e56 100644
> -
From: Harald Hoyer
https://bugzilla.redhat.com/show_bug.cgi?id=772073
---
src/core/execute.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/core/execute.c b/src/core/execute.c
index 5083af9..fabd38e 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -1516,6 +1516,
From: Harald Hoyer
https://bugzilla.redhat.com/show_bug.cgi?id=772073
---
src/core/execute.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/core/execute.c b/src/core/execute.c
index 5083af9..c881e56 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -1516,6 +1516,16
From: Harald Hoyer
https://bugzilla.redhat.com/show_bug.cgi?id=772073
---
src/core/execute.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/core/execute.c b/src/core/execute.c
index 5083af9..c881e56 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -1516,6 +1516,16
Hello,
I have a question about systemd and cgroups:
"mount | grep cgroups" shows that only one entry has name=systemd.
and is mounted on /sys/fs/cgroup/systemd . (see below the full output
of "mount | grep cgroups"
Is it true that all other cgroup entry shown by "mount | grep cgroups"
were not mou
From: Harald Hoyer
https://bugzilla.redhat.com/show_bug.cgi?id=772073
---
src/core/execute.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/core/execute.c b/src/core/execute.c
index 5083af9..c881e56 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -1516,6 +1516,16
On Mon, Apr 8, 2013 at 2:27 PM, Lennart Poettering
wrote:
> systemd-cgtop has also been updated to be 'pipeable' for processing with
> further shell tools.
It's been pipeable for quite some time, specifically since the changes
to allow a fixed number of cycles and avoid truncating cgroup names.
38 matches
Mail list logo