On Wed, Nov 12, 2014 at 3:35 PM, Michael Biebl wrote:
> Am 12.11.2014 um 23:59 schrieb Cameron Norman:
>> But will services depending on network.target be started then? Or will
>> they be prevented from starting in the case of an auto interface not
>> being configured?
>
> How is that relevant for
Am 12.11.2014 um 23:59 schrieb Cameron Norman:
> But will services depending on network.target be started then? Or will
> they be prevented from starting in the case of an auto interface not
> being configured?
How is that relevant for this patch?
--
Why is it that all of the instruments seeki
El mié, 12 de nov 2014 a las 6:30 , Michael Biebl
escribió:
Am 12.11.2014 um 05:04 schrieb Cameron Norman:
On Tue, 11 Nov 2014 20:05:53 +0100 Michael Biebl
wrote:
Am 11.11.2014 um 20:01 schrieb Michael Biebl:
> Attached is a patch against /etc/init.d/networking.
> While we discussed yeste
Am 12.11.2014 um 05:04 schrieb Cameron Norman:
> On Tue, 11 Nov 2014 20:05:53 +0100 Michael Biebl wrote:
>> Am 11.11.2014 um 20:01 schrieb Michael Biebl:
>> > Attached is a patch against /etc/init.d/networking.
>> > While we discussed yesterday, to only run "udevadm settle" if there are
>> > any a
On Tue, 11 Nov 2014 20:05:53 +0100 Michael Biebl
wrote:
> Am 11.11.2014 um 20:01 schrieb Michael Biebl:
> > Attached is a patch against /etc/init.d/networking.
> > While we discussed yesterday, to only run "udevadm settle" if
there are
> > any auto interfaces, I changed it, to also cover allow
severity 766943 critical
tags 766943 + jessie sid
stop
Since no one of you guys objected, and since it seems the appropriate
level as per definition...
>critical
>makes unrelated software on the system (or the whole system) break, or
>causes serious data loss, or introduces a security hole on sy
Hey.
There's also that issue:#768514
It's smells after one of these three bugs here (#766943, #727073 and
#766291), but OTOH, the 30s sleep ugly workaround is still in place
right now, and all other daemons can bind to their addresses,... bind9
however can not and fails at start.
Cheers,
Chris.
Hey guys.
Probably nothing new here, right?
Since this seems to be a quite serious bug, i.e. no networking (which
makes the nodes completely unreachable/unusable) when systemd is used
which is the default init system in jessie... I'd say that this
qualifies to be a RC bug.
Unless you disagree (p
Oh and I should perhaps add:
With allow-auto AND the sleep: all services find their addresses and
start up correctly.
With allow-auto WITHOUT the sleep,... well when waiting for my script to
restart the networking, then of course no service (but ssh, which I've
restarted from the script) was runn
On Mon, 2014-10-27 at 13:55 +0100, Andrew Shadura wrote:
> /etc/init.d/networking doesn't check for systemd or anything, and it
> works fine with sysv-rc, so this probably not a bug in ifupdown, but
> in systemd.
Well... I still suspect that something *is* fishy here... I mean the
other two bugs a
On Mon, 2014-10-27 at 13:51 +0100, Michael Biebl wrote:
> allow-auto is a synonym for auto.
Sure, I know,... I just do it for cosmetic reasons ^^
> The ifup@.service unit, as shipped by systemd, only deals with
> "allow-hotplug" interfaces.
Ah? Okay... interesting,... didn't know that...
This is
Am 27.10.2014 um 14:19 schrieb Michael Biebl:
> That /etc/init.d/networking succeeds to bring up eth0 under sysvinit but
> not under systemd, might have different reasons:
> a/ the service is not started at all or in the wrong order
> b/ the timining is different under systemd and there is a race s
Hi Andrew,
Am 27.10.2014 um 13:55 schrieb Andrew Shadura:
> Hello,
>
> On 27 October 2014 13:51, Michael Biebl wrote:
>> allow-auto is a synonym for auto.
>> The ifup@.service unit, as shipped by systemd, only deals with
>> "allow-hotplug" interfaces.
>> "auto" interfaces are handled by /etc/ini
Hello,
On 27 October 2014 13:51, Michael Biebl wrote:
> allow-auto is a synonym for auto.
> The ifup@.service unit, as shipped by systemd, only deals with
> "allow-hotplug" interfaces.
> "auto" interfaces are handled by /etc/init.d/networking, which is
> shipped by ifupdown. Therefore re-assignin
Control: reassign -1 ifupdown
Am 27.10.2014 um 06:56 schrieb Christoph Anton Mitterer:
> I did however find what is likely to be the issue:
> Changing "allow-auto eth0" to "allow-hotplug eth0" in /e/n/interfaces...
> and the system did come up again every time (and I did like 5-8 reboots
> with al
On Mon, 2014-10-27 at 06:56 +0100, Christoph Anton Mitterer wrote:
> # systemctl -l status sks.service
> ● sks.service - (null)
>Loaded: loaded (/etc/init.d/sks)
>Active: active (running) since Mon 2014-10-27 06:52:22 CET; 4min 21s ago
> Process: 1991 ExecStart=/etc/init.d/sks start (co
affects 766943 ifupdown
stop
Hey.
Some more information:
I finally came in again and could place some cron script which manually
brings the network up and restarts ssh every 15mins when it can't ping
google.com so testing should get a lot easier then.
I also have some additional informati
Package: systemd
Version: 215-5+b1
Severity: important
Hi.
Tonight I switched my last server still running with sysvinit to
systemd, since I've experience no major problems with it on my other
systems.
That server however, didn't come up anymore (i.e. not even pinging
back).
I've sent a Ctrl-Al
18 matches
Mail list logo
