It does seem like an inconsistency. I'm guessing it's just not
implemented. We don't have instance support yet for mounts, and that's
because it's hard to do in a way that preserves consistency and
flexibility. I can't think of any reason why that would be the case
for instance services + *.d overr
I posted this to another, related thread, but here's the relevant
commit and reasoning:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=b3ac5f8cb98757416d8660023d6564a7c411f0a0
On Tue, Apr 9, 2013 at 5:15 AM, Tetsuo Handa
wrote:
> Andrey Borzenkov wrote:
>> This seems to be yest another fa
Here is the commit with some background:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=b3ac5f8cb98757416d8660023d6564a7c411f0a0
On Thu, Apr 11, 2013 at 11:42 PM, David Strauss wrote:
> On Mon, Apr 8, 2013 at 3:45 PM, Linda Walsh wrote:
>> Is it something that systemd needed to have? I.
On Mon, Apr 8, 2013 at 3:45 PM, Linda Walsh wrote:
> Is it something that systemd needed to have? I.e. if it is made
> private would systemd care? If not, why would it have
> been made shared?
>
> Maybe a default in mount for root changed?
Having the default mount propagation be "shared" solves
2013/4/11 Koen Kooi :
>> On Wed, Apr 10, 2013 at 11:00 PM, Koen Kooi
>> wrote:
>>> restarting it once it fails
>>
>> Is "it" the socket or the service?
>
> socket
I believe I experienced this with PHP-FPM when I injected the sockets
by abusing PHP-FPM's internal env var method for preserving soc
Op 11 apr. 2013, om 21:09 heeft David Strauss het
volgende geschreven:
> On Wed, Apr 10, 2013 at 11:00 PM, Koen Kooi
> wrote:
>> restarting it once it fails
>
> Is "it" the socket or the service?
socket
___
systemd-devel mailing list
systemd-devel
On Wed, Apr 10, 2013 at 11:00 PM, Koen Kooi wrote:
> restarting it once it fails
Is "it" the socket or the service?
--
David Strauss
| [email protected]
| +1 512 577 5827 [mobile]
___
systemd-devel mailing list
[email protected]
On Thu, Apr 11, 2013 at 05:47:55PM +0200, Tom Gundersen wrote:
> This tool reads modules.devname from the current kernel directory and writes
> the information
> out in the tmpfiles format so that systemd-tmpfiles can use this to create
> the required device
> nodes before systemd-udevd is starte
systemd-tmpfiles has had support for creation of static nodes for some time (to
replace copying nodes from /lib/udev/). Make sure these nodes are created before
udev is started.
Also, drop support for creating static nodes based on modules.devname from
systemd-udevd. This allows it to run witohut
This tool reads modules.devname from the current kernel directory and writes
the information
out in the tmpfiles format so that systemd-tmpfiles can use this to create the
required device
nodes before systemd-udevd is started on boot.
This makes sure nothing but kmod reads the private files unde
Thanks!
KV
On Thu, Apr 11, 2013 at 5:37 PM, Kay Sievers wrote:
> On Thu, Apr 11, 2013 at 12:46 PM, Kevin Wilson wrote:
>> Hello,
>> This is a default fedore 18 machine with default kernel. Kernel came
>> with the F18 disto, no changes. No special things like LXC/OpenVZ. So
>> I guess no 3rd part
On Thu, Apr 11, 2013 at 12:46 PM, Kevin Wilson wrote:
> Hello,
> This is a default fedore 18 machine with default kernel. Kernel came
> with the F18 disto, no changes. No special things like LXC/OpenVZ. So
> I guess no 3rd party mount any cgroup.
>
>>then systemd itself will mount all the resource
From: Harald Hoyer
Also clarify rd.luks.uuid and luks.uuid in the manual.
https://bugzilla.redhat.com/show_bug.cgi?id=905683
---
Fixed some whitespace error.
man/kernel-command-line.xml | 2 ++
man/systemd-cryptsetup-generator.xml | 26 +-
src/cryptsetup/c
From: Harald Hoyer
When using "-p" and "-b" in combination with "-u", the output is not
what you would expect. The reason is the sd_journal_add_disjunction()
call in add_matches_for_unit() and add_matches_for_user_unit(), which
adds two ORs without taking the other conditions to every OR.
Adding
'Twas brillig, and Kay Sievers at 11/04/13 12:51 did gyre and gimble:
> On Thu, Apr 11, 2013 at 1:46 PM, Colin Guthrie wrote:
>
>> Should we then consider trying to push a new default name scheme into
>> the kernel side such that they come up as "eth-ng0" etc. by default
>> allowing any userspace
On Thu, Apr 11, 2013 at 1:46 PM, Colin Guthrie wrote:
> Should we then consider trying to push a new default name scheme into
> the kernel side such that they come up as "eth-ng0" etc. by default
> allowing any userspace stuff to rename them to "eth1" or whatever
> without so much likelihood of s
On Thu, Apr 11, 2013 at 12:41 PM, Colin Guthrie wrote:
> 'Twas brillig, and Andrey Borzenkov at 11/04/13 10:25 did gyre and gimble:
>> On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald
>> wrote:
>>> /usr/share/doc/systemd/README.Fedora-18
>>>
>>> - A hacky workaround that allows udev to rename netw
Am 11.04.2013 13:46, schrieb Colin Guthrie:
> 'Twas brillig, and Harald Hoyer at 11/04/13 12:27 did gyre and gimble:
>> Only
>> $ rpm -qf /lib/udev/rename_device
>> initscripts-9.45-2.fc19.x86_64
>>
>> kicks in and renames interfaces according to the ifcfg-* files, if HWADDR is
>> set, and if the
'Twas brillig, and Harald Hoyer at 11/04/13 12:27 did gyre and gimble:
> Am 11.04.2013 12:55, schrieb Reindl Harald:
>>
>>
>> Am 11.04.2013 12:41, schrieb Colin Guthrie:
>>> 'Twas brillig, and Andrey Borzenkov at 11/04/13 10:25 did gyre and gimble:
On Thu, Apr 11, 2013 at 2:50 AM, Reindl Haral
Am 11.04.2013 13:27, schrieb Harald Hoyer:
> Just add "net.ifnames=0 biosdevname=0" to the kernel command line and you
> don't
> need any 70-persistent-net.rules. Udev will not try to rename your interfaces.
>
> $ rpm -qf /lib/udev/rename_device
> initscripts-9.45-2.fc19.x86_64
>
> kicks in an
Am 11.04.2013 13:13, schrieb Colin Guthrie:
> But regardless, unless the patch to allow renaming is carried locally in
> the distro for a long time
> (http://pkgs.fedoraproject.org/cgit/systemd.git/tree/0005-F18-Revert-udev-network-device-renaming-immediately-.patch?h=f18)
> then eventually the sup
Am 11.04.2013 13:13, schrieb Colin Guthrie:
> Any scripts that assume names are also broken by design and should
> really be written better to deal with things more gracefully, although I
> totally agree that breaking existing setups is bad
aha and WHAT should scripts calling tons of cli-command
Am 11.04.2013 12:55, schrieb Reindl Harald:
>
>
> Am 11.04.2013 12:41, schrieb Colin Guthrie:
>> 'Twas brillig, and Andrey Borzenkov at 11/04/13 10:25 did gyre and gimble:
>>> On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald
>>> wrote:
/usr/share/doc/systemd/README.Fedora-18
- A ha
'Twas brillig, and Reindl Harald at 11/04/13 12:10 did gyre and gimble:
>
>
> Am 11.04.2013 13:02, schrieb Tom Gundersen:
>> On Thu, Apr 11, 2013 at 12:55 PM, Reindl Harald
>> wrote:
>>> there are THOUSANDS of virtual machines with only two NICs and no
>>> race-problems
>>
>> In the case where
'Twas brillig, and Reindl Harald at 11/04/13 11:55 did gyre and gimble:
>
>
> Am 11.04.2013 12:41, schrieb Colin Guthrie:
>> 'Twas brillig, and Andrey Borzenkov at 11/04/13 10:25 did gyre and gimble:
>>> On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald
>>> wrote:
/usr/share/doc/systemd/READM
Am 11.04.2013 13:02, schrieb Tom Gundersen:
> On Thu, Apr 11, 2013 at 12:55 PM, Reindl Harald
> wrote:
>> there are THOUSANDS of virtual machines with only two NICs and no
>> race-problems
>
> In the case where no renaming is done at all, and it JustWorks, then
> you can still disable persist
From: Harald Hoyer
Also clarify rd.luks.uuid and luks.uuid in the manual.
https://bugzilla.redhat.com/show_bug.cgi?id=905683
---
man/kernel-command-line.xml | 2 ++
man/systemd-cryptsetup-generator.xml | 26 +-
src/cryptsetup/cryptsetup-generator.c | 22 +
From: Harald Hoyer
If the key file cannot be accessed, we can at least ask for the
password.
---
src/cryptsetup/cryptsetup.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index ae4aa8d..29b0dae 100644
--- a/src/cryptsetup/cryp
On Thu, Apr 11, 2013 at 12:55 PM, Reindl Harald wrote:
> in real life there are THOUSANDS of setups with only one ethernet interface
> there are THOUSANDS of virtual machines with only one network interface
In these cases you can disable persistent interface naming and they
will stay at eth0.
>
Am 11.04.2013 12:41, schrieb Colin Guthrie:
> 'Twas brillig, and Andrey Borzenkov at 11/04/13 10:25 did gyre and gimble:
>> On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald
>> wrote:
>>> /usr/share/doc/systemd/README.Fedora-18
>>>
>>> - A hacky workaround that allows udev to rename network interf
Hello,
This is a default fedore 18 machine with default kernel. Kernel came
with the F18 disto, no changes. No special things like LXC/OpenVZ. So
I guess no 3rd party mount any cgroup.
>then systemd itself will mount all the resource controllers
that are compiled into the kernel.
How ?
I don't kn
'Twas brillig, and Andrey Borzenkov at 11/04/13 10:25 did gyre and gimble:
> On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald wrote:
>> /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
Am 11.04.2013 11:25, schrieb Andrey Borzenkov:
> On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald wrote:
>> /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
On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald wrote:
> /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-persist
34 matches
Mail list logo
