Hey.
On Tue, 2014-12-09 at 15:14 +0100, Aljoscha Lautenbach wrote:
> tried Michael Biebl's suggestions.
Oops... I've missed that mail,... sorry Michael.
Next time the issue happens (probably after the next update to systemd)
I'll check whether either of the two commands resolves the issue witho
On Tue, 2014-12-09 at 19:40 +0100, Christoph Anton Mitterer wrote:
> Next time the issue happens
I can confirm now the same behaviour as Aljoscha described in message
#46.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
___
On Sun, 2015-02-22 at 17:53 +, Colin Watson wrote:
> Well, um, in either case, isn't it pretty weird that "systemctl status"
> shows the unit as failed while the boot progress system shows it as OK?
> Feels like a systemd bug to me.
Arguably, I'mm CCing the systemd guys, perhaps they can help
On Sun, 2015-03-29 at 05:57 +0200, Marco d'Itri wrote:
> From resolved.conf(5):
>
> Any per-interface DNS servers obtained from
> systemd-networkd.service(8) take precedence over this setting, as do
> any servers set via DNS= above or /etc/resolv.conf. This setting is
> hence o
On Sun, 2015-03-29 at 06:55 +0200, Michael Biebl wrote:
> Am 29.03.2015 um 06:35 schrieb Christoph Anton Mitterer:
> > I'm really not inclined to start another security discussion, since
> > that's already lost cause in Debian... but the appropriate way would be
> &g
On Sun, 2015-03-29 at 12:47 +0200, Marco d'Itri wrote:
> So far, it is. If you still want to argue about this (which I something
> that I strongly recommend against!), then you should explain in detail
> the threat model that you are trying to address and how the current
> configuration would be
btw: Letting people use unknowingly a specific nameserver may have also
further consequences than just privacy leakage.
Since e.g. the Google nameservers are well known to allow people to
circumvent DNS blocks, they're quite likely under special observation by
governmental agencies in autocratic c
I think this may even require some broader discussion, perhaps on d-d,
about which position Debian has towards privacy.
This case here of silently defaulting to a big greedy company who is
well-known for being part of the US' world-wide surveillance program is
just the tip of an ice-berg.
Obviou
On Tue, 2015-04-07 at 22:22 +0200, Marco d'Itri wrote:
> So far the current default looks like a reliable
Actually it's not, many networks block access to external resolvers
since the "proper ones" are given via DHCP.
As it was pointed out here before, protocols like DHCP are the proper
and reliab
On Tue, 2015-04-07 at 22:45 +0200, martin f krafft wrote:
> In fact, the only software I know
> that uses defaults for out-of-the-box operation (apart from all the
> desktop-ware, which is a different beast) is ntpd using
> pool.ntp.org, but this is a project started by a DD and uses
> sufficientl
On Tue, 2015-04-07 at 23:07 +0200, Marco d'Itri wrote:
> I do not believe this to be true.
Well, but it is. It's similar to many networks blocking port 25.
> I totally agree with this statement, and indeed systemd-resolved
> defaults to use DHCP-provided resolvers if available.
Sure, noone disp
On Wed, 2015-04-08 at 10:45 +0200, Michael Biebl wrote:
> Just like resolved needs explicit opt in by the admin (the service is
> disabled by default).
I don't think that this actually changes anything.
Everything is in a way explicitly opt in, when you install Debian.
The point is can some behavi
On Thu, 2015-04-30 at 18:37 -0400, J Phelps wrote:
> So now you guys have forced "systemd" on all of us, and it doesn't even work.
No one has forced anything on you. sysvinit is still available and
maintained in Debian, you can simply use that if you like it more.
> ** (systemadm:21458): CRITICA
Package: systemd
Version: 215-17
Severity: normal
Hey.
I was running some tests on the differences between a systemd
that was kept constantly at sid level and such that was upgraded
from wheezy to jessie.
During that I've noticed that /etc/subuid and /etc/subgid have
entries like the following
Control: reassign -1 adduser
Control: reopen -1
Control: retitle -1 adduser: missing or legacy subuid/subgid entries for some
users/groups
On Thu, 2015-05-07 at 02:49 +0200, Michael Biebl wrote:
> You should direct those questions to the adduser maintainer.
> Those files are not managed by syst
Hey experts.
Perhaps you could help me with the following.
What I'd basically like to have is a way to stop/restart (but not start)
other units along with the "current" unit.
Example:
Consider services like fail2ban, which e.g. somehow hook up into
iptables-rules.
The default of fail2ban does
Package: systemd
Version: 228-2
Severity: wishlist
Hey.
Not sure whether this is a wishlisht, bug or whether I just oversee anything ;-)
When configuring the kernel for serial console ouput, i.e. sth. like
console=ttySx,115200n8 ...
I'd actually like to have output on both, serial consol and VG
Control: forwarded -1 https://github.com/systemd/systemd/issues/2079
On Tue, 2015-12-01 at 15:02 +0100, Michael Biebl wrote:
> > ForwardToConsole=yes
> > TTYPath=/dev/ttySx
I just gave that a try and it seems not to be what I want... as it
forwards *everything* on the journal to the serial consol
Package: systemd-container
Version: 229-5
Severity: minor
Hi.
btrfs-tools is now a dummy transitional package. Please recommend btrfs-progs
instead :)
Chris.
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
htt
Package: systemd
Version: 229-5
Severity: normal
Hi.
This issue happens since quote a while (> 1 year?).
When "some" packages are upgraded, logins, at least via ssh, are considerably
delayed.
journalctl output when trying to log in via ssh:
May 11 03:03:43 kronecker sshd[3051]: Postponed publi
Something that happened before sometimes (but not always), just
happened again.
I tried to restart systemd-logind, which sometimes just worked and
fixed the issue:
# systemctl restart systemd-logind.service
Job for systemd-logind.service failed because a timeout was exceeded. See
"systemctl stat
Control: forcemerge 770135 823987
On Wed, 2016-05-11 at 11:59 +0200, Michael Biebl wrote:
> My guess is, that it's the D-Bus restart and only indirectly related
> to
> the library upgrade.
mhh and the dbus restart is "suggested" because of the libgcc update...
I see..
> needrestart has a blackli
There were some updates just before,...
First I didn't restart any service (via needrestart).
Login still succeeded in a timely manner then.
Afterwards I restarted dbus.service, and then the issue occurs.
So, Michael, your assumption seems to be confirmed.
Cheers,
Chris.
smime.p7s
Description:
Hey.
Another update on this... similar situation:
I was updating packages, needrestart offers me to restart dbus.service,
but ALSO systemd-logind.service.
# needrestart
Scanning processes...
Package: init-system-helpers
Version: 1.46
Severity: important
Hi.
Not sure why the following happens:
# update-rc.d nbd-server disable
update-rc.d: error: nbd-server Default-Start contains no runlevels, aborting.
Trying to enable it gives the same error:
# update-rc.d nbd-server enable
update-
Hey.
Thanks for having a look.
Actually I've noticed the trailing whitespace in the init-script and
removed it for a test, but then it still didn't work... and since I was
quite busy I didn't further check the code.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
__
Package: udev
Version: 233-10
Severity: wishlist
Hi.
Some possible improvements:
1)
README.Debian, mentions:
/lib/systemd/network/01-mac-for-usb.link
however this seems to no longer exist.
2)
Also it mentions "on VMs remove the file
/etc/udev/rules.d/80-net-setup-link.rules instead".
Is th
Hi.
One addition on this, with 226-2, udev.postinst started to create:
/etc/systemd/network/50-virtio-kernel-names.link
on some systems.
AFAIU, this is only just there for "easy migration" of systems that
used to have "old" interface naming.
So it might be worth to tell people in README.Debian in
> there's really not much difference in performance or effect.
Sure... it's just about establishing BCPs :-)
> > Christoph Anton Mitterer [2017-07-12 15:12 +0200]:
> > One addition on this, with 226-2, udev.postinst started to create:
> > /etc/systemd/network/50-virtio-kernel-names.
Just one more thing:
You used "/etc/systemd/network/dmz.link"
Wouldn't it be better to use something like 10-dmz.link?
Otherwise people may choose a name which is lexically after
/lib/systemd/network/99-default.link
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
On Fri, 2017-07-14 at 08:22 +0200, Martin Pitt wrote:
> Eeek, indeed! Thanks for spotting.
Thanks for improving and your other Debian work :-)
smime.p7s
Description: S/MIME cryptographic signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-mai
Hey Michael.
On Tue, 2017-10-10 at 18:49 +0200, Michael Biebl wrote:
> Is this issue still reproducible with a recent version from stretch
> or
> buster? I failed to reproduce it myself with a stretch VM.
At least I haven't encountered it anymore since ages.
I did once or twice (even with the li
Hi.
First, this is not about bashing systemd (I'm actually mostly in favour
of it and use it since a long while)...
Now that it get's the default init in Debian... and becomes more and
more mandatory (e.g. that other stuff like policykit basically depends
on it) I wondered how Debian solves the i
Hi Michael.
On Wed, 2014-05-21 at 00:14 +0200, Michael Biebl wrote:
> I have no idea what you mean with passive dependencies.
Well I hope I've had that explained by the examples I gave.
What I mean was:
Usually none of the services depends (directly) on ,
or or or ...
One goal of systemd was
Hi Tollef,...
Let me see...
On Wed, 2014-05-21 at 16:35 +0200, Tollef Fog Heen wrote:
> > By looking at that goal (which is a good goal of course) we "loose"
> > however that strict serialisation that we more or less had with
> > sysvinit.
> sysvinit isn't serialised today either.
Sure... I mean
On Thu, 2014-05-22 at 16:40 +0200, Tollef Fog Heen wrote:
> $network is translated to network.target for LSB services, so it is in
> fact the same thing.
Sure...
> You're pointing out that «the network is up» is ill-defined. That is a
> correct observation and technically never true in a depend
Hi.
Shouldn't have this some much higher severity? The modules might be
required for booting the system... with systemd the long standing way of
how /etc/modules worked breaks and it's also still documented as it
should work.
Also I don't agree with upstream and what Michael wrote in #15:
Not hav
On Fri, 2014-05-23 at 16:46 +0200, Tollef Fog Heen wrote:
> What's the deal about your use of ellipsises all the time? It looks
> really weird and I'm not sure what you're trying to communicate by using
> them.
Uhm, guess I'm using that too much. It's just some kind of a break/pause
- as you seem
Hi Tollef, et al
Sorry for the long delay... I've forwarded that idea now to upstream:
https://bugs.freedesktop.org/show_bug.cgi?id=80169
Lennart told me that there is a new special target network-pre.target in
the next version... but I think it's not really a good solution for what
I want,... b
On Wed, 2014-07-02 at 20:39 +0200, Svante Signell wrote:
> these packages. And, there won't be 50 000
> foo-must-die packages.
Packages are there to install software, not to prevent sucht
installation.
This is a perversion of any package management system.
What you want can be done via apt_prefe
Package: systemd
Version: 208-6
Severity: normal
Hi.
1) It seems that systemd's reportbug scripts always attach ridiculously
big
log/debug files that it attaches to the sent mail.
An otherwise empty bug report just produced a file:
l /tmp/reportbug-systemd-20140727-23596-mFq0pl
-rw--- 1 cal
On Sat, 2014-10-04 at 15:06 +0200, Tollef Fog Heen wrote:
> /etc/inittab is a sysvinit-only configuration file, so this is
> expected. Arguably, we should warn once if the inittab has been changed
> from the shipped default.
Maybe it would be a good idea to provide one central file, where you
de
reopen 756248
stop
Hey.
Thanks for implementing what you've already did, but reopening this for
now for the following question:
When people chose to submit the debug information, these mails still get
pretty bug (just tried, and on my system a fresh empty report, get's
more than half a MB).
Is
Subject: systemd: compress debug information sent with reportbug
Package: systemd
Version: 215-5+b1
Severity: wishlist
Hi.
As mentioned already in #756248 and as per Michael's request there, I
guess I better do this as long as I'm still able to ;) ... and suggest
that the following:
When using r
Package: systemd
Version: 215-5+b1
Severity: important
Tags: security
Hi.
Maybe I just miss something, but AFAIU, network-pre.target is not guaranteed
to run before any networking is brougt up (which is the whole point of
network-pre.target).
network.target has an After= on network-pre.target,
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
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
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/i
On Mon, 2014-10-27 at 14:50 +0100, Michael Biebl wrote:
> Christoph, can you...
Sure, but I'm a bit busy today and may not find time until tonight or
tomorrow... so please stay tuned :)
smime.p7s
Description: S/MIME cryptographic signature
___
Pkg-syst
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
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
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.
On Sat, 2014-11-08 at 18:20 +0100, Andrew Shadura wrote:
> I don't think it's right that the bug is assigned at ifupdown.
> Neither ifupdown nor its init scripts make any assumptions regarding
> init system being used, so I don't see how is it more helpful
> to have me dealing with this, but not s
I just made some new tests.
It seems the issue appears less often then before (where it failed in
like 9 out of 10 boots),... this time it's more like failure in 3 of 4
boots.
But there was a new kernel, and maybe that somehow changed some timing
issues?
Anyway, attached is a new log files from
Hey Michael...
On Mon, 2014-11-10 at 03:40 +0100, Michael Biebl wrote:
> allow-hotplug interfaces are configured when the actual hardware is
> available.
But you have seen what I've wrote previously,.. that I *do* in fact also
have issues with allow-hotplug... so there most likely is something
fi
I'm a bit busy right now so I haven't had time to look into your last
few mails... will read+test everything once I have some time left.
smime.p7s
Description: S/MIME cryptographic signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-mainta
On Tue, 2014-11-18 at 00:43 +0100, John Paul Adrian Glaubitz wrote:
> > This decision has been made in gross violation of constitution §6.3.6,
> > being summoned to override a maintainer’s choice while the solution
> > was still under discussion.
> >
> > I urge the systemd maintainers not to take
Package: systemd
Version: 215-6
Severity: normal
Hi.
Since I've upgraded to -6 (and basically nothing else was upgraded
since then except gcc) I have the phenomenon that ssh logins take
considerably longer:
What auth.log shows on the server is this (right after the client
connects):
Nov 19 04:2
Control: tag -1 - moreinfo
Hey Martin, intrigeri.
On Wed, 2014-11-19 at 07:40 +0100, Martin Pitt wrote:
> I. e. with -5 it worked?
Let me triple-check:
a) with -6:
Nov 19 21:46:56 kronecker sshd[30685]: Accepted publickey for root from
2001:a60:14d9:9201:6267:20ff:fe09:9aa4 port 35506 ssh2:
Hey guys...
On Mon, 2014-11-10 at 04:08 +0100, Michael Biebl wrote:
> > But you have seen what I've wrote previously,.. that I *do* in fact also
> > have issues with allow-hotplug... so there most likely is something
> > fishy there (or in unit files of services) as well..
> > So is this somethin
On Mon, 2014-11-10 at 04:36 +0100, Michael Biebl wrote:
> To provide such a syncronisation point, i.e. having network.target and
> network-online.target [1] properly hooked up, I've implemented a PoC
> ifupdown-wait-online service. You can get it from [2] and enable it via
> "systemctl enable ifup
Hey.
On Tue, 2014-11-11 at 20:01 +0100, Michael Biebl wrote:
> We discussed this a bit more yesterday, and we came to the conclusion,
> that for jessie, it's probably the simplest solution, if we explicitly
> call "udevadm settle" in /etc/init.d/networking before it ifup's any
> devices.
> A "ude
retitle 770135 systemd: ssh logins considerably delayed (until PAM timeout)
when systemd is upgraded but the system not rebooted
stop
Hi.
I've just confirmed the very same problem on the upgrade to -7.
ssh logins were considerably delayed until that PAM timeout happened
again,... no daemon-ree
I'm having the same issue,... so maybe it comes from #766943?
I've only checked the fix for that on the server nodes (where that delay
of 1-2 mins doesn't really get noticed) - not on my desktop node.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
__
On Mon, 2014-12-01 at 18:00 +0100, Michael Biebl wrote:
> Very likely, yes. If you use DHCP, it can easily take a few seconds for
> your network to be configured.
> And now that /etc/init.d/networking both handles allow-hotplug and auto
> interfaces and blocks for ifup to complete for those interf
On Mon, 2014-12-01 at 18:55 +0100, Michael Biebl wrote:
> Not quite sure what you mean with "other fix"? Can you elaborate?
I mean the udevsettle, which apparently causes this delay now...
I just see it coming that gazillions of people cause to whine about that
delay :(
> For jessie we decided
66 matches
Mail list logo
