SYSTEMD: Give us a option for upstart
jspaleta at gmail.com
Tue Jun 14 14:10:51 UTC 2011
On Tue, Jun 14, 2011 at 5:32 AM, Reindl Harald <h.reindl at thelounge.net> wrote:
> i think this would be a good idea
> PHP (my main language) is fighting with traling slash or not troubles
> over all the years, but there is nothing to stop the boot-process and
> systemd is a very different level of software
Let's be clear...the bug was actually in mount...not systemd. And the
fix has been committed for the mount binary according the bug ticket
against the utils-linux package. So the problem has been solved very
quickly after the _correct_ developers were notified via the
established bug tracking mechanism.
And its a weird bug for mount...not what I would have expected.
Simple test outside of systemd for everyone falling along using a ntfs
disk I just happened to have.
First using an entry like this without a slash
/dev/sdb1 /mnt ntfs defaults 0 0
mount /mnt and mount /mnt/ both work and the drive mounts
Second using an entry like this with a slash
/dev/sdb1 /mnt/ ntfs defaults 0 0
mount /mnt fails to mount with an error and mount /mnt/ succeeds
What my very simple test shows is that this is totally inconsistent
behavior on the part of mount in handling trailing slashes or the lack
thereof. There's no good reason why that 1 failure should be
happening especially when clearly the mount binary is internally
manipulating trailing slashes in some cases. If it wasn't then I
should have gotten a failure in the first case.
If you want to be passionate and be upset about system breakage, that
is absolutely your right to do so. But I caution you that you are not
channeling your passion effectively. I hope in the future you budget
some time as a volunteer to be involved in the pre-release testing so
you can help catch problems prior to release. I also hope you learn
to be less aggressive when discussing issues with people with whom you
don't have an established working relationship.
And please, avoid prejudicing a new component of the software stack
when things like this happen. New code typically does a better job at
tickling implicit assumptions than experienced sysadmins and testers.
In this case, mount is broken, and has been broken for years, and
we've all been living with that brokenness and not realizing it
because we've conditioned ourselves to interact with mount in a way
that avoids the breakage. Please, lay the blame at the feet of the
correct piece of software. In this case the mount binary is behaving
inconsistently and has undocumented quirks that have gone unfixed for
YEARS until this bug was filed and fixed. FIXED...I can't stress that
enough...the fix has already been committed and we are just waiting
for packages now.
All systemd was doing was breaking an _undocumented_ _implicit_
_assumption_ that the mount command was using to map mount cmdline
mountpoints to fstab entry mountpoints. Mount was assuming that when
an fstab entry had a trailing slash then the mount cmdline mntpoint
argument would also have a trailing slash and mount was failing when
the trailing slash was missing in the cmdline argument. Is there a
good reason for mount to do this? I can't think of one so far noone
has defended mount's behavior in this regard. And as far as I know its
not a documented behavior of mount. And since its not documented there
was no reason that anyone (including the systemd authors) could know
that stripping the trailing slash when parsing the fstab entry would
cause mount to fail. Doubly so when the slash is missing mount
processes cmndline mountpoints with trailing slashes without issue.
Undocumented implicit assumptions are _bugs_ that cause all sorts of
problem up and down the software stack. Spending days and days and
days complaining about the piece of software that runs into such an
implicit assumption is not the way to work through the problem.
Identifying the software with the implicit assumption and either
getting it documented or fixed to behave in a consistent,
programmatic, robust manner is _always_ the proper way forward.
This will be my last response to you on any of these threads. And
while I understand why you are upset, and I respect your right to be
upset over this issue, I am extremely disappointed in the choices you
have made in expressing your opinions on the matter. I will not reward
you further with interaction and attention until such time that its
clear that you've learned how to tempter your emotion and can approach
discussion over problems with more humility and less aggression.
More information about the devel