Am 27.08.2014 um 22:48 schrieb Thomas Bächler:
> Am 27.08.2014 um 20:25 schrieb Ivan Shapovalov:
>> On Wednesday 27 August 2014 at 20:19:45, Lennart Poettering wrote:
>>> On Wed, 27.08.14 20:26, Ivan Shapovalov (intelfx...@gmail.com) wrote:
>>>
>>>> This i
Am 27.08.2014 um 20:25 schrieb Ivan Shapovalov:
> On Wednesday 27 August 2014 at 20:19:45, Lennart Poettering wrote:
>> On Wed, 27.08.14 20:26, Ivan Shapovalov (intelfx...@gmail.com) wrote:
>>
>>> This is as proposed by Thomas in review of my hibernate-resume patchset.
>>>
>>> The objective ben
Am 27.08.2014 um 09:22 schrieb Ivan Shapovalov:
>>> +[Unit]
>>> +Description=Resume from hibernation using device %f
>>> +Documentation=man:systemd-hibernate-resume@.service(8)
>>> +DefaultDependencies=no
>>> +BindsTo=%i.device
>>
>> What's the purpose of BindsTo= as opposed to Requires= here. They
Am 26.08.2014 um 22:17 schrieb Ivan Shapovalov:
> This can be used to initiate a resume from hibernation by path to a swap
> device containing the hibernation image.
>
> The respective templated unit is also added. It is instantiated using
> path to the desired resume device.
Really great stuff,
Am 18.08.2014 um 12:41 schrieb Tom Gundersen:
>> 1) The enp3s0 interface does not activate on boot. I need to restart
>> networkd manually to make it work.
>
> Hm, that is decidedly uncool. It seems we are not aware of the link.
> Could you try with Environment=SYSTEMD_LOG_LEVEL=debug in your serv
Am 18.08.2014 um 12:41 schrieb Tom Gundersen:
>> 1) The enp3s0 interface does not activate on boot. I need to restart
>> networkd manually to make it work.
>
> Hm, that is decidedly uncool. It seems we are not aware of the link.
> Could you try with Environment=SYSTEMD_LOG_LEVEL=debug in your serv
Hello Tom,
I am using systemd 215-4 from Arch Linux.
I have the following configuration files in /etc/systemd/network:
# 01-lan.network
[Match]
Name=enp3s0
[Network]
Address=10.23.42.4/26
Gateway=10.23.42.3
# 01-qemu.netdev
[NetDev]
MACAddress=1a:de:ad:be:ef:01
Name=qemu
Kind=tap
# 01-qemu.ne
Am 02.07.2014 14:29, schrieb Daniel Drake:
> If I'm reading things right, actually the default behaviour is (when
> no hints are supplied in kernel cmdline) :
> 1. systemd runs fsck on root from initramfs
> 2. systemd mounts root fs ro
> 3. switch-root onto real system
> 4. systemd-fsck-root ru
Am 30.04.2014 10:23, schrieb Tom Gundersen:
>> On 04/29/2014 09:30 PM, Tom Gundersen wrote:
>>
>>> You can easily start the sockets early, but make the daemon itself
>>> wait for the key generation to finish.
>>
>>
>> Thanks. Can you provide an example?
>
> I guess the last three files here would
Am 23.04.2014 07:00, schrieb Lennart Poettering:
> On Thu, 27.03.14 23:41, Thomas Bächler (tho...@archlinux.org) wrote:
>
>> On virtually any newer Asus mainboard, the eeepc-wmi driver is loaded.
>> It exposes a backlight device despite the lack of any physical backlight
>
Am 22.04.2014 10:33, schrieb Tom Gundersen:
> On Tue, Apr 22, 2014 at 9:37 AM, Thomas Bächler wrote:
>> I'm
>> CC'ing the original reporter, maybe he can give more information.
>
> I think you forgot to do that...
Strange stuff - he is listed in CC in the mail
Am 22.04.2014 07:07, schrieb Lennart Poettering:
> On Fri, 18.04.14 11:34, Thomas Bächler (tho...@archlinux.org) wrote:
>
>> According to [1], when a persistent timer runs its service on boot, it
>> delays startup.
>
> Humm? What precisely do you mean by "dela
According to [1], when a persistent timer runs its service on boot, it
delays startup. That itself isn't a problem, but it delays Type=idle
units, in particular, agetty@tty1.service, prohibiting login until it
finishes.
I hooked up OnCalendar=daily/Persistent=true timers to Type=oneshot
units that
Am 16.04.2014 06:10, schrieb Andy Johnson:
> Hello, systemd-devel,
>
> I saw this in the manpage of systemd-networkd.service (in the systemd git
> tree)
>
> systemd-networkd.service, systemd-networkd — Network manager
>
> My question is: is systemd-networkd.service a replacement for the
> Netwo
Am 14.04.2014 18:16, schrieb Lennart Poettering:
> On Mon, 14.04.14 18:01, Francis Moreau (francis.m...@gmail.com) wrote:
>
>> Hello,
>>
>> "gummiboot install" fails when ESP is MD RAID1 device using metadata 0.9
>> or 1.0.
>>
>> I don't think using such RAID for ESP would lead to issue.
>>
>> Is
Am 05.04.2014 17:32, schrieb Thomas Bächler:
> Am 05.04.2014 11:35, schrieb Tom Gundersen:
>> On Wed, Apr 2, 2014 at 8:18 PM, Thomas Bächler wrote:
>>> If a persistent timer has no stamp file yet, it behaves just like a normal
>>> timer until it runs for the first ti
Am 10.04.2014 03:35, schrieb Lennart Poettering:
>> Simply try:
>> int func(...) {
>> static bool network_namespace_warning = false;
>> ...
>>
>> if (!network_namespace_warning) {
>> network_namespace_warning = true;
>> log_warn("...");
>> }
>> }
>>
>> Zbyszek
Am 05.04.2014 11:35, schrieb Tom Gundersen:
> On Wed, Apr 2, 2014 at 8:18 PM, Thomas Bächler wrote:
>> If a persistent timer has no stamp file yet, it behaves just like a normal
>> timer until it runs for the first time. If the system is always shut down
>> while the timer
Am 03.04.2014 17:13, schrieb Barry Scott:
> But as soon as the script exits the mount.ntfs process is killed off by
> something? systemd-udevd maybe?
From man udev's section on RUN:
" This can only be used for very short-running foreground
tasks. Running an event process for a long peri
Am 03.04.2014 11:36, schrieb David Herrmann:
> On Thu, Apr 3, 2014 at 11:08 AM, Tom Gundersen wrote:
>> Or is there actually a bug going on here? My impression from reading
>> related discussions was that "systemd.log_level=debug loglevel=debug"
>> triggers some bug (so in particular "debug" now t
Am 27.03.2014 23:41, schrieb Thomas Bächler:
> On virtually any newer Asus mainboard, the eeepc-wmi driver is loaded.
> It exposes a backlight device despite the lack of any physical backlight
> devices. This fake backlight device has max_brightness set to 0. Since
> the introdu
If a persistent timer has no stamp file yet, it behaves just like a normal
timer until it runs for the first time. If the system is always shut down
while the timer is supposed to run, a stamp file is never created and
Peristent=true has no effect.
This patch fixes this by creating a stamp file wi
Am 28.03.2014 12:41, schrieb Tom Gundersen:
> Side note: we might want to revisit how old kernels we want to
> support. Especially for building, we may want to just require
> something a bit more recent (maybe 3.10 or 3.12)?
The kernel version during build is not an issue. Kernel headers are
never
Am 26.03.2014 00:28, schrieb Kay Sievers:
> * Timer units gained a new Persistent= switch. If enabled
> timers configured this way will save to disk when they have
> been last triggered. This information is then used on next
> reboot to possible execute overdue
On virtually any newer Asus mainboard, the eeepc-wmi driver is loaded.
It exposes a backlight device despite the lack of any physical backlight
devices. This fake backlight device has max_brightness set to 0. Since
the introduction of the clamp_brightness function, systemd-backlight
tries to write
Am 25.03.2014 01:40, schrieb Lennart Poettering:
>> This is just a kludge... Why is system.journal to be treated differently?
>> It seems that the proper fix is to set the mode on the directory properly
>> during installation.
>
> Precisely, packaging script are expected to properly chown and setf
systemd does not need or use CONFIG_EFI_VARS anywhere, this should
be CONFIG_EFIVAR_FS instead.
---
README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/README b/README
index ace13cf..b0bf5e8 100644
--- a/README
+++ b/README
@@ -80,7 +80,7 @@ REQUIREMENTS:
CONFIG_S
Am 12.03.2014 16:34, schrieb Lennart Poettering:
> This should then run an break where the incorrect OOM happens. Then, get
> me a backtracke please:
>
> bt full
Sending it inline, should be readable enough. It seems like
udev_device_get_parent() fails in enumerate_partitions(). The device it
Am 12.03.2014 01:30, schrieb Lennart Poettering:
> Heya!
>
> Many bugfixes, and a number of new features:
>
> http://www.freedesktop.org/software/systemd/systemd-211.tar.xz
>
>
The instance name is never escaped in the udev rule, but unescaped in the unit.
This results in the following error message on Asus boards:
Failed to get backlight or LED device 'backlight:eeepc/wmi': No such file or
directory
---
units/systemd-backli...@.service.in | 6 +++---
1 file changed,
Am 28.02.2014 10:02, schrieb WaLyong Cho:
> systemd is already provide a special unit. If the type of unit is
> service then that is 'basic.target'. Additionally default extra
> dependency can be listed in system.conf and then other service unit will
> have "After=" dependency implicitly.
> In conf
I am trying to set properties on scopes or services of my user instance,
for example:
systemctl --user set-property --runtime foobar.scope CPUShares=150
This command returns without error, but in the journal, I get messages
like this:
systemd[5054]: Failed to set cpu.shares on
/user.slice/user-
Am 24.02.2014 17:10, schrieb Lennart Poettering:
> On Fri, 21.02.14 11:55, Thomas Bächler (tho...@archlinux.org) wrote:
>
>> Both systemd-analyze and systemd-run only access org.freedesktop.systemd1
>> on the bus. This patch allows using systemd-run --user and
>> syste
Am 21.02.2014 11:55, schrieb Thomas Bächler:
> Both systemd-analyze and systemd-run only access org.freedesktop.systemd1
> on the bus. This patch allows using systemd-run --user and systemd-analyze
> --user even if the user session's bus is not properly integrated with the
>
Am 21.02.2014 17:03, schrieb Tom Gundersen:
>> What about Zbigniews idea of using something like:
>> ConditionDirectoryNotEmpty=/etc/systemd/network/
>>
>> Would that work?
>
> We'd have to look in all the possible folders, and there may (and due
> to 99-deafult.link, always will) be files there,
Both systemd-analyze and systemd-run only access org.freedesktop.systemd1
on the bus. This patch allows using systemd-run --user and systemd-analyze
--user even if the user session's bus is not properly integrated with the
systemd user unit.
---
src/analyze/analyze.c | 2 +-
src/run/run.c
There was a copy-paste error introduced in commit
c2ba3ad6604ef2e189d7e0a36d696e84d3ab
which causes the following error when using timer units:
Assertion '(x->type == SOURCE_MONOTONIC && y->type == SOURCE_MONOTONIC) ||
(x->type == SOURCE_REALTIME && y->type == SOURCE_REALTIME)'
failed at src
Am 20.02.2014 17:33, schrieb Dave Reisner:
> Hi all,
>
> I'm working on packaging the systemd 209 release, and I expect to have
> pkgrel=1 into [testing] in a few hours, barring any unforseen problems.
> It's a huge release (nearly 2000 commits since 208), and I don't
> anticipate that this will m
Am 17.02.2014 21:27, schrieb Manuel Reimer:
> As soon as a bigger coredump (about 500 MB) is to be stored, the whole
> system slows down significantly. Seems like storing such big amounts of
> data takes pretty long and is a very CPU hungry process...
I completely agree. Since the kernel ignores t
Am 29.01.2014 03:49, schrieb Andrey Borzenkov:
>> Zbyszek's argument for the patch, however, is that following the
>> recommended WantedBy= behavior already applies the same Before=
>> dependency,
>
> Where is *this* documented? Unless I misunderstand what you say.
The documentation (and code) re
Am 27.01.2014 05:18, schrieb David Anderson:
> Jan 26 19:10:38 ironman kernel: e1000e :00:19.0 eth0: Intel(R)
> PRO/1000 Network Connection
> ...
> Jan 26 19:10:38 ironman kernel: e1000e :02:00.0 eth1: Intel(R)
> PRO/1000 Network Connection
> ...
> *Jan 26 19:10:38 ironman systemd-udevd[153
Am 21.01.2014 09:33, schrieb Holger Schurig:
> on my systemd v208 + many patches from the Fedora 21 source RPM i get
> TWO error messages in my journal when I login as root:
>
> 09:27:58 systemd-logind[118]: Failed to start unit user@0.service:
> Unit user@0.service failed to load: No such file or
Am 13.01.2014 02:47, schrieb Kay Sievers:
> On Mon, Jan 13, 2014 at 8:07 AM, Greg KH wrote:
>> On Sun, Jan 12, 2014 at 11:48:56PM +0100, Dominique Michel wrote:
>>> I need that pc for production, so I rapidly installed another
>>> distribution without systemd. So this problem is solved for me, but
Am 21.12.2013 12:49, schrieb Tom Gundersen:
>> -r = add_fsck(f, what, where, type, passno);
>> -if (r < 0)
>> -return r;
>> +if(is_device_path(what)) {
>> +r = add_fsck(f, what, where, type, passno);
>> +if (r < 0)
>> +
This fixes a regression introduced in 64e70e4 where the mount fails
when fstab is misconfigured with fs_passno > 0 on a virtual file
system like tmpfs.
---
src/fstab-generator/fstab-generator.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/fstab-generator/fstab-ge
With the current logic, a user will never be garbage-collected, since its
manager will always be around. Change the logic such that a user is
garbage-collected when it has no sessions and linger is disabled.
---
src/login/logind-user.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/src/l
Am 12.12.2013 15:38, schrieb Lennart Poettering:
> On Wed, 11.12.13 19:56, Thomas Bächler (tho...@archlinux.org) wrote:
>
>> With the current logic, a user will never be garbage-collected, since its
>> manager will always be around. Change the logic such that a user is
>>
Am 12.12.2013 15:38, schrieb Lennart Poettering:
> On Wed, 11.12.13 19:56, Thomas Bächler (tho...@archlinux.org) wrote:
>
>> With the current logic, a user will never be garbage-collected, since its
>> manager will always be around. Change the logic such that a user is
>>
Am 11.12.2013 19:56, schrieb Thomas Bächler:
> With the current logic, a user will never be garbage-collected, since its
> manager will always be around. Change the logic such that a user is
> garbage-collected when it has no sessions and linger is disabled.
This seems to fix my curren
With the current logic, a user will never be garbage-collected, since its
manager will always be around. Change the logic such that a user is
garbage-collected when it has no sessions and linger is disabled.
---
src/login/logind-user.c | 12
1 file changed, 12 deletions(-)
diff --git
Am 10.12.2013 22:55, schrieb Thomas Bächler:
> # /run/systemd/users/1000
> # This is private data. Do not parse.
> NAME=test
> STATE=closing
> RUNTIME=/run/user/1000
> SERVICE=user@1000.service
> SLICE=user-1000.slice
> REALTIME=1386712031039381
> MONOTONIC=14242584
Am 10.12.2013 20:07, schrieb Lennart Poettering:
>> The screenshot actually has the full output of 'loginctl user-status
>> $user', which includes all open sessions of the user (in this case,
>> none). I also verified with 'ps' that all processes by that user are
>> gone, except the (sd-pam) and sy
Am 10.12.2013 19:19, schrieb Lennart Poettering:
> That service should be reference counted by the sessions of the users
> logging in. I should hence go away if the users successfully log out
> from their last session.
That sounds like the behaviour I would expect.
> Your screenshot shows the use
Am 10.12.2013 18:37, schrieb Lennart Poettering:
>> What's the distribution you are using? Using udevadm settle for lvm is a
>> waste of boot time and isn't even guaranteed to work (ask Lennart, Kay
>> or Greg K-H for the full speech). It's a hackish workaround for LVM's
>> inability to activate vo
In systemd 208 and latest systemd git, every user gets a new
user@.service instance when they login. However, when their last session
exits, that service is not terminated.
After a few weeks of uptime on one of my servers, dozens of
user@.service units are running, belonging to users that logged i
Am 07.12.2013 22:29, schrieb Robert Milasan:
> From systemd-analyze dump:
>
> Wants: systemd-udevd.service
> WantedBy: lvm2-activation-early.service
> WantedBy: lvm2-activation.service
> Before: lvm2-activation-early.service
> Before: sysinit.target
>
Am 20.11.2013 15:02, schrieb Tom Gundersen:
>> what does this mean? Does it override the value of the first section,
>> the second section or does it create a new section?
>
> Yeah, in this case it would not make sense. However, this stuff is
> opt-in only, and unit files don't opt-in (currently n
Am 20.11.2013 14:38, schrieb Tom Gundersen:
> Pass on the line on which a section was decleared to the parsers, so they
> can distinguish between multiple sections (if they chose to). Currently
> no parsers take advantage of this, but a follow-up patch will do that
> to distinguish
>
> [Address]
>
Am 29.10.2013 17:52, schrieb Kay Sievers:
>> None of this explains why systemd no longer applies certain controllers
>> by default. Previously, systemd would attach cpu controllers to each
>> service by default. Now, it only groups your processes in the systemd
>> tree, but does not touch any cgrou
Am 29.10.2013 17:21, schrieb Colin Guthrie:
> Hi,
>
> 'Twas brillig, and Umut Tezduyar at 29/10/13 15:17 did gyre and gimble:
>> I have noticed DefaultControllers= option is no longer in system.conf
>> file. Has it been moved to somewhere else or are all controllers
>> default controllers by defau
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
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 fsck@.service 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
Am 24.09.2013 21:53, schrieb Kelly Anderson:
> If I'm not mistaken, the intent way back in the early stages of systemd was
> to
> eliminate /etc/fstab and use .mount files exclusively. Since it was never
> fully implemented I took the prerogative to make it work on my systems.
> I've been using
Am 01.10.2013 15:26, schrieb Karel Zak:
>>> 2. If /etc/fstab is missing, systemd must create a valid fstab (in this
>>> case
>>> /run/fstab) so that fsck runs properly.
>>
>> Not following on this one really... If fsck fails if it doesn't find any
>> fstab, then this is really something to fix i
Am 01.10.2013 12:30, schrieb Zbigniew Jędrzejewski-Szmek:
>> Now, according to the fstab(5) manpage, the root fs should have passno 1
>> and everything else should have passno 2. We could ensure the same
>> behaviour by having After=systemd-root-fsck.service in
>> systemd-fsck@.service.
> Serializi
Am 01.10.2013 12:15, schrieb Colin Guthrie:
> 'Twas brillig, and Thomas Bächler at 01/10/13 10:18 did gyre and gimble:
>> Am 01.10.2013 02:58, schrieb Lennart Poettering:
>>> Now, if we have the initrd, then I figure root-fsck.service doesn't make
>>> much s
Am 01.10.2013 02:58, schrieb Lennart Poettering:
> Now, if we have the initrd, then I figure root-fsck.service doesn't make
> much sense, but there's something missing I think: if we use
> fsck@.service for the root device, how do we then communicate to the
> root-fsck.service on the host that the
Am 01.10.2013 05:10, schrieb Lennart Poettering:
b) is tempting. Given fsck's improved internal ordering handling, is
there actually a usecase for ordering the fsck's? I can't think of any
off the top of my head...
>>>
>>> I struggle coming up with one. I mean, the only I could think
Am 30.09.2013 17:14, schrieb Colin Guthrie:
> Hi,
>
> Just trying to debug the problem mentioned in the subject. I'm wanting
> to use the new device names in stage 2 of our installer (some closing
> config routines write the interface name into some conf files etc), but
> when udev rules kick in,
---
units/systemd-fsck-root.service.in | 1 -
1 file changed, 1 deletion(-)
diff --git a/units/systemd-fsck-root.service.in
b/units/systemd-fsck-root.service.in
index 4388314..4162983 100644
--- a/units/systemd-fsck-root.service.in
+++ b/units/systemd-fsck-root.service.in
@@ -19,5 +19,4 @@ Type=
---
src/gpt-auto-generator/gpt-auto-generator.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/gpt-auto-generator/gpt-auto-generator.c
b/src/gpt-auto-generator/gpt-auto-generator.c
index ca54925..97b4742 100644
--- a/src/gpt-auto-generator/gpt-auto-generator.
---
src/fstab-generator/fstab-generator.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 6cecb4e..83aba7d 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-
FsckPassNo is listed as a compatibility option that shouldn't be used
in new units. Keeping compatibility with fstab's old fs_passno field
serves no particular purpose on a systemd system.
This patch series removes all usage of FsckPassNo from all generated
and shipped units:
* fstab-generator no
---
src/fstab-generator/fstab-generator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 9efccb9..6cecb4e 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-gen
Am 11.09.2013 17:08, schrieb Lennart Poettering:
> Using FsckPassNo= as a way to add that dep sucks really, because the
> ordering it does is stupid and fsck can do the ordering internally
> anyway these days...
So, shouldn't systemd-fstab-generator omit that entirely, too? Instead,
every mount wi
In the manpage for systemd.mount(5), the following section is included:
COMPATIBILITY OPTIONS
The following option is also available in the "[Mount]" section,
but exists purely for compatibility reasons and should not be used in
newly written mount files.
FsckPassNo=
The
Am 21.08.2013 13:53, schrieb Tom Gundersen:
> I'd like to move some of the default dependency logic from the fstab generator
> to core. This should remove some redundancy and also improve consistency
> between mount units and fstab entries.
>
> The first patch simply enables default dependencies i
Am 19.08.2013 21:05, schrieb Zbigniew Jędrzejewski-Szmek:
>> Now to do the --populate archlinux, you need to have an archlinux
>> keyring in /usr/share/pacman/keyrings/. If you look at the
>> `archlinux-keyring` package in arch, that should give you some ideas.
> So, I've created a simple archlinux
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Am 19.08.2013 13:25, schrieb Thomas Bächler:
> Am 19.08.2013 11:58, schrieb Harald Hoyer:
>> On 08/19/2013 11:21 AM, Thomas Bächler wrote:
>>> Am 19.08.2013 10:34, schrieb Harald Hoyer:
>>>> Hmm, the naming "
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Am 19.08.2013 11:58, schrieb Harald Hoyer:
> On 08/19/2013 11:21 AM, Thomas Bächler wrote:
>> Am 19.08.2013 10:34, schrieb Harald Hoyer:
>>> Hmm, the naming "luks.options" is IMHO poorly chosen. "options"
>&
Am 19.08.2013 10:34, schrieb Harald Hoyer:
> Hmm, the naming "luks.options" is IMHO poorly chosen. "options" as an option
> name... hmm. Also crypttab can contain more encryption modes, than LUKS.
>
> If you want to reflect crypttab, why not specify something like:
>
> [rd.]crypttab=;;;
So, syst
When running from initrd, entering a wrong passphrase usually means that
you cannot boot. Therefore, we allow trying indefinitely.
---
This is useful together with Tom's latest patch. On my system, I use
rd.luks.options=allow-discards,tries=0
so unless booting succeeds, I will be prompted for a p
Am 17.08.2013 17:27, schrieb Zbigniew Jędrzejewski-Szmek:
> Hi,
>
> I was trying to get the arch installation example in systemd-spawn
> to work on Fedora. My intent is to package pacman and pacstrap for
> Fedora, to make it easy to play with distributions. Fedora already
> has alien and dpkg/apt-
Am 08.08.2013 15:19, schrieb Michal Sekletar:
> Calling enable on template units doesn't make sense since it is possible
> to enable instances directly and users are not forced to use Alias=
> trickery anymore.
Actually, it would make sense to do this instead:
http://www.mail-archive.com/systemd-d
Am 25.07.2013 10:18, schrieb Frederic Crozat:
> Le mercredi 24 juillet 2013 à 18:41 -0300, Gerardo Exequiel Pozzi a
> écrit :
>> Signed-off-by: Gerardo Exequiel Pozzi
>> ---
>> units/systemd-udev-settle.service.in | 1 -
>> units/systemd-udev-trigger.service.in | 1 -
>> units/systemd-udevd-cont
Am 17.07.2013 17:58, schrieb Zbigniew Jędrzejewski-Szmek:
> So, now we have -o short, -o short-monotonic, and --iso-dates.
> I'm sure we'll add a relative timestamp mode like the excellent one in
> dmesg --human output in recent util-linux. So I'd say that it makes
> sense to deprecate short-monoto
Am 16.07.2013 14:58, schrieb Ramkumar Ramachandra:
> Ramkumar Ramachandra wrote:
>> It seems that UM does not have a proper tty system; I force
>> systemd to use the /dev/console by doing:
>>
>> $ mv
>> /etc/systemd/system/getty.target.wants/{getty@tty1.service,getty@console.service}
>
> Where
Am 11.06.2013 10:34, schrieb Colin Guthrie:
> Without reading the code etc., I'm running systemd with that commit
> (v204) and I don't get any conflicts for my -.mount unit...
>
> So it seems that code is not run for me for whatever reason.
>
> After a very quick glance at the code, it could just
Am 23.04.2013 21:51, schrieb Albert Strasheim:
> is causing some headaches with some services of ours that use unshare
> to get a new mount namespace and make some private mounts which we
> don't want propagated.
Proper solution: Directly after the unshare, run either
mount("none", "/", "none",
Am 18.04.2013 16:44, schrieb Lennart Poettering:
> On Thu, 18.04.13 16:38, Thomas Bächler (tho...@archlinux.org) wrote:
>
>> Am 18.04.2013 16:04, schrieb Lennart Poettering:
>>> That said, screen should probably set up a new PAM session of its own
>>> and detach fro
Am 18.04.2013 16:04, schrieb Lennart Poettering:
> That said, screen should probably set up a new PAM session of its own
> and detach from the original one.
That sounds like a good idea - unfortunately, screen does not seem to
have PAM session support at all, and I couldn't find the obvious place
Am 16.04.2013 15:12, schrieb Tom Gundersen:
> +static void write_human(FILE *out, char module[], char devname[], char type,
> unsigned int maj, unsigned int min)
[...]
> +static void write_tmpfile(FILE *out, char devname[], char type, unsigned int
> maj, unsigned int min)
[...]
> +static int
Am 03.04.2013 19:02, schrieb Lennart Poettering:
> On Wed, 03.04.13 17:02, Harald Hoyer (har...@redhat.com) wrote:
>
>>> Well, this explanation is too short. You need to clarify that this only
>>> has an effect on devices listed in fstab with their device mapper path
>>> (i.e. rather than LABEL= o
Am 19.03.2013 23:13, schrieb Gary Artim:
> Thinking I should modify to add a "After=" for nfs.target, any one
> think this is the wrong approach or alternate options, I'd do
> something like:
Sufficiently recent systemd versions have the 'RequiresMountsFor='
option to deal with this, see 'man syst
Am 13.02.2013 10:29, schrieb Colin Guthrie:
>> Hmm, but what happens then if people do run
>>
>> systemctl enable getty@.service?
In my eyes, doing this always seemed wrong, I wouldn't mind if it
returned an error.
>> We really need to get the story right on this, I guess, so that
>> something us
Am 13.02.2013 03:38, schrieb Lennart Poettering:
> Hmm, indeed. There's a missing connection between unit_start() failing
> and timer_unit_notify()...
>
> I added this to the todo list now, to get fixed...
From my short look into the code, the same holds for path_unit_notify().
signature.asc
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
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 rai
Am 05.02.2013 14:30, schrieb Baurzhan Muftakhidinov:
> What concerns me here is that there is no consistency on less powerful
> machine.
There is no consistency. Period. Not on more powerful and not on less
powerful machines. There never was, there never will be.
In some form, this "problem" has
Am 22.01.2013 23:11, schrieb Lennart Poettering:
> Anybody else is coming who'd like to join us? Anybody from ArchLinux
> attending FOSDEM? SUSE? Or the other distributions?
It seems like nobody from Arch Linux will be there this year. My
original plans to go to FOSDEM have been overthrown by fami
1 - 100 of 114 matches
Mail list logo