On Monday 2013-01-07 15:26, Lennart Poettering wrote:
>BTW, Kay and I were thinking about coming up with a simple scheme that
>could pre-initialize a couple of files in /etc and /var that cannot
>really sensibly be dropped. For example, UID assignemnts unfortunately
>cannot be shipped in packages
Hi all,
systemd will call crash() if received fatal signals. It will produce a
core dump for analysis.
However, it seems signal handler has a separated stack, so can't back
trace the place where exactly the fatal signal triggered.
Any idea?
BTW,
* It will be helpful if could print /proc/1/maps,
Hi all,
Systemd will report "Starting/Started ..." of units when boot-up, but
it doesn't tell users what's happening when the boot-up process
blocks(e.g. waiting for timeout, my personal story was swap partition
changed but forgot to modify fstab, which caused a hangup each
boot-up).
It would be
On Tue, Feb 12, 2013 at 4:49 AM, Jan Engelhardt wrote:
>
> On Monday 2012-11-26 15:49, Kay Sievers wrote:
>>>
>>> I guess that answers the "binaries" bit, but probably doesn't answer why
>>> system units are in /usr/lib/systemd/system/ rather than, say,
>>> /usr/share/systemd/systemd. I think that
On Wednesday 2012-12-05 05:59, AbH Belxjander Draconis Serechai wrote:
>
>It is asking for the same resource twice in the way I read that
>
>aren't IPv4 and IPv6 sharing socket space?
They share address space; IPv4 is blended into IPv6 at
::::/96, and so something listening on [::] a
On Monday 2012-11-26 15:49, Kay Sievers wrote:
>>
>> I guess that answers the "binaries" bit, but probably doesn't answer why
>> system units are in /usr/lib/systemd/system/ rather than, say,
>> /usr/share/systemd/systemd. I think that's the "configuration files"
>> part of Dave's question.
>
>Our
Contrary to it's own packaging guidelines, these symlinks are created
in /etc/. While technically not a problem, this makes it harder
for folks installing from git that want to override these settings
(either masking or otherwise).
Moving the links to $(systemunitdir) resolves.
---
Makefile.am |
On 12 February 2013 00:14, Oleksii Shevchuk wrote:
> Function that converts byte array to hex string
> ---
> src/shared/util.c | 23 +++
> src/shared/util.h | 1 +
> 2 files changed, 24 insertions(+)
>
> diff --git a/src/shared/util.c b/src/shared/util.c
> index 24f9e7e..6db
If coredump goes to raw file, compute hash sum of it and store to
journal. Feature is optional, if libgrcypt enabled (HAVE_GCRYPT)
---
Makefile.am | 9
src/journal/coredump.c| 48 +++
src/journal/journald-server.h | 2 +-
Function that converts byte array to hex string
---
src/shared/util.c | 23 +++
src/shared/util.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/src/shared/util.c b/src/shared/util.c
index 24f9e7e..6dbfe29 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -1368
---
src/journal/coredumpctl.c | 258 +-
1 file changed, 207 insertions(+), 51 deletions(-)
diff --git a/src/journal/coredumpctl.c b/src/journal/coredumpctl.c
index b6e5581..9ad8d3b 100644
--- a/src/journal/coredumpctl.c
+++ b/src/journal/coredumpctl.c
@
Save core dumps to /var/log/journal/MACHINE-ID/coredump/COMM.CORE-ID.
If no access rights or directory not present, save core to journal.
When saving to file, use journal message id
fc2e22bc6ee647b6b90729ab34a250b2 instead of
fc2e22bc6ee647b6b90729ab34a250b1, and use field COREDUMP_FILE to
store r
Fixes this bug:
alxchk > systemctl --user set-environment A=B
alxchk > systemctl --user show-environment | grep ^A=
A=B
alxchk > systemctl --user daemon-reexec
alxchk > systemctl --user show-environment | grep ^A=
alxchk >
---
src/core/manager.c | 29 +
1 file changed,
Current one:
- If StopWhenUnneeded=yes and RequiredBy=, WantedBy=, BoundBy= empty
Then stop unit.
The side effect is:
- If user starts unit, that not wanted by any started target, then unit
will be immediately stopped.
The problems are:
- The user can not be sure that the launch of a unit
From: "Zeeshan Ali (Khattak)"
Expose system, application, publisher and boot system IDs.
This patch uses (though not requires) my pending patches to
libblkid:
http://article.gmane.org/gmane.linux.utilities.util-linux-ng/7234
---
src/udev/udev-builtin-blkid.c | 13 -
1 file changed,
And now with patch files.
2013/2/11 Daniel Buch
> I made tests for:
>
> strv_merge
> strv_merge_concat
> strv_append
>
0003-test-strv.c-added-strv_append-test.patch
Description: Binary data
0002-test-strv.c-added-strv_merge_concat-test.patch
Description: Binary data
0001-test-strv.c-added
On Mon, 11.02.13 21:32, Tomasz Torcz (to...@pipebreaker.pl) wrote:
>
> On Mon, Feb 11, 2013 at 09:16:08PM +0100, Lennart Poettering wrote:
> >
> > a) we need to treat all devices of the same type the same, a logic
> >depending on the order of discovery is not possible.
>
> Can we treat de
I made tests for:
strv_merge
strv_merge_concat
strv_append
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Mon, Feb 11, 2013 at 09:16:08PM +0100, Lennart Poettering wrote:
>
> a) we need to treat all devices of the same type the same, a logic
>depending on the order of discovery is not possible.
Can we treat devices depending on which USB port they are connected to?
If so, there could be (cus
On Mon, 11.02.13 12:59, Stef Bon (stef...@gmail.com) wrote:
> Huh?? I do care since I think the way these plugable devices are not
> handled optimal, especially from the point if view from the user.
>
> And since you say it's simple by just make the call, can you just
> describe what to do to mak
On Mon, 11.02.13 09:39, Colin Guthrie (gm...@colin.guthr.ie) wrote:
> I'm not sure about unique ids, but I would have thought that the
> pluggable devices would have been easier to identify individually via
> serial numbers that were actually different in each device precisely for
> this reason. F
On Mon, 11.02.13 09:45, Stef Bon (stef...@gmail.com) wrote:
>
> 2013/2/8 Lennart Poettering :
> > On Fri, 08.02.13 12:27, Stef Bon (stef...@gmail.com) wrote:
> >
> >>
> >> > No, udev contains the information which devices together make up a
> >> > seat. Hence, it is also udev where it is stored w
h readahead-[replay|collect] enabled:
> http://www.garyvdm.co.za/bootchart-20130211-1328.svg
>
> Output of `/usr/lib/systemd/systemd-readahead analyze /.readahead` :
> http://www.garyvdm.co.za/systemd-readahead-analyze
>
> There is no output in `journalctl -u systemd-readahead
On my Arch Linux ARM system, everything can be set in
/etc/network.d/wired-eth0. By default, the version of
/etc/network.d/wired-eth0 is for DHCP. I switched that to the version for a
fixed IP address first:
> # cd /etc/network.d
> # mv wired-eth0{,.orig}
> # cp examples/ethernet-static ./wir
Consider the following timer unit:
[Unit]
Description=test timer
[Timer]
OnCalendar=*-*-* *:*:00/10
Combine this with the following service:
[Unit]
Description=test timer test unit
ConditionACPower=true
[Service]
ExecStart=/bin/true
The unit is started every 10 seconds as expected. However, w
Hi
Feel free to redirect me to some other place if needed :)
So, we have a BootCD that is intended for remotely managed machines
In a nutshell, we need to redefine the whole init sequence, and what we had on
f12 and f14 boxes was essentially a set of 2 init scripts, one for rough system
initiali
Hi all.
This is my first post to this list, so I just want to say I thank you
too all those
who wrote systemd.
systemd-readahead-replay does not seem to be doing what it should.
Bootchart with readahead-[replay|collect] enabled:
http://www.garyvdm.co.za/bootchart-20130211-1328.svg
Output of
2013/2/11 Colin Guthrie :
> 'Twas brillig, and Stef Bon at 11/02/13 08:45 did gyre and gimble:
>>>
>> Look this is getting us nowhere.
>>
>> You do not seem to understand my point.
>>
>> How does this rule look like? I'm asking because I cannot immagine one.
>
> But calling those methods will gener
Am 11.02.2013 01:31, schrieb NeilBrown:
> On Sat, 9 Feb 2013 21:49:47 +0100 Thomas Bächler
> wrote:
>
>> Right now, the rules that run blkid on raid arrays are executed after
>> the assembly rules. This means incremental assembly will always fail
>> when raid arrays are again physical components
'Twas brillig, and Stef Bon at 11/02/13 08:45 did gyre and gimble:
> 2013/2/8 Lennart Poettering :
>> On Fri, 08.02.13 12:27, Stef Bon (stef...@gmail.com) wrote:
>>
>>>
No, udev contains the information which devices together make up a
seat. Hence, it is also udev where it is stored wheth
On Fri, Feb 08, 2013 at 12:38:55AM +0100, Lennart Poettering wrote:
> > diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
> > index 058f34d..b1938c7 100644
> > --- a/src/fsck/fsck.c
> > +++ b/src/fsck/fsck.c
> > @@ -321,9 +321,10 @@ int main(int argc, char *argv[]) {
> > }
> >
> >
2013/2/8 Lennart Poettering :
> On Fri, 08.02.13 12:27, Stef Bon (stef...@gmail.com) wrote:
>
>>
>> > No, udev contains the information which devices together make up a
>> > seat. Hence, it is also udev where it is stored whether something is
>> > used in "docking station" style or in "new seat" st
32 matches
Mail list logo
