[systemd-devel] https://bugzilla.redhat.com/show_bug.cgi?id=1047614

Reindl Harald h.reindl at thelounge.net
Wed Feb 12 11:37:25 PST 2014

Am 12.02.2014 20:18, schrieb Greg KH:
> On Wed, Feb 12, 2014 at 08:05:47PM +0100, Reindl Harald wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1047614
>> Product: 	Red Hat Enterprise Linux 7
>> Component: 	systemd (Show other bugs)
>> Version: 	7.0
>> Hardware: 	Unspecified Unspecified
>> Priority 	urgent Severity high
>> first reported more than 3 months ago
>> https://bugzilla.redhat.com/show_bug.cgi?id=1023788
> This issue has been debugged already, see the mailing list archives

it needs to be backported and reach distributions and finally users
nobody has any gain from discussions burried in list-archives
more than 3 months is way too long

>> maybe systemd-upstream should consider slow down development
>> and spend more energy in quality and stability
> How exactly would you suggest something like this be done?

most of the issues (the above is only one) was introduced
with features resulting in more and more processes on a
tiny system (sd-pam processes for any userid ever fired up
a process) and a user at uid.service, hard dependencies to
a running dbus-daemon and what not

there where times a stable server was up for months without
any of these processes and "messagebus" as well as Consolkit
disabled completly resulting in 5 userland processes for a

what about pushing not that much new features and large changes
in a tiny timeframe and spend more of the time in bug-triage
of existing problems?

don't get me wrong but the above was reported long before F20 GA
and there are some never seen any QA at all or how can it be that
bugs like "Failed to open private bus connection: Failed to connect
to socket /run/user/0/dbus/user_bus_socket" or any other ever used
uid are present over months or make it in a release at all? one
boot of the machine and i see them - why? because i look at the
syslog after any reboot and expect the same from upstream

there are more and more loglines all day long resulting in
nobody cares if there are some important burried

what's that - a workaround relying on a typo?

>> (In reply to digimer from comment #11)
>> Requires=mutil-user.target
>> BTW at least for me, this "mutil" typo is essential for this hack to work. Do the
>> s/mutil/multi/ fix or remove the whole line and it no longer does. Too lazy at
>> the moment to figure out why, just did s/mutil/doesnt-exist/ locally to make it
>> more clear and moving on...

these are all regressions from F19 to F20

sometimes it feels like systemd-upstrearm has a release-and-forget-strategy
and don't care about the downstream distributions and issues there nor
how bad the impact of them for how long is

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140212/7aecea00/attachment.pgp>

More information about the systemd-devel mailing list