Re: Bug#693387: Pre-approval for unblock: sysvinit/2.88dsf-33
control: severity -1 wishlist
control: tags -1 +moreinfo
[2012-11-16 13:48] Roger Leigh <rleigh@codelibre.net>
> On Fri, Nov 16, 2012 at 02:33:54PM +0100, Michael Biebl wrote:
> > I'm redirecting this to #693398 since I don't want to spam the unblock
> > request bug.
> >
> > On 16.11.2012 11:37, Roger Leigh wrote:
> > > On Fri, Nov 16, 2012 at 02:11:13AM +0100, Michael Biebl wrote:
> >
> > >>
> > >> As already mentioned on IRC: checkroot-bootclean is kinda odd.
> > >> It cleans up /run/, /run/lock *after* the tmpfs has been mounted, so
> > >> this cleanup looks entirely pointless.
> > >
> > > The main point of this script was to clean /tmp prior to mounting a
> > > tmpfs, as well as /lib/init/rw (for historical reasons). It also
> > > handles cleaning of /run and /run/lock; for platforms which don't
> > > support a tmpfs, or where the admin has explicitly disabled tmpfs
> > > mounting.
> >
> > /run-on-tmpfs is not really optional (at least not on kfreebsd and
> > Linux). So this only seems to be relevant for Hurd.
> > Especially cleaning up /run/lock seems completely pointless, since we
> > already cleanup /run.
> > Also, keep in mind that clean_all is run *three* times during boot.
> > So for all non-Hurd users, which probably make up 100% of our user base
> > (minus rounding errors), we run those clean up rules unnecessarily.
> >
> > While I could see the point of cleaning up /var/lock and /var/run, if
> > you mount a tmpfs on those dirs, that is no longer what's happening with
> > them being migrated to symlinks on upgrades.
>
> While we don't expose a configuration option (RAMRUN) to disable
> tmpfs on /run, we don't actively prevent users from disabling it by
> e.g. commenting out the line in mountkernfs. It's not supported,
> and I certainly won't recommend anyone do that. But there were
> several requests to restore boot-time cleaning by people who were
> doing that, and this covers that use case.
>
> While I'm open to revisiting this for jessie, it costs very little
> to do this, and I don't want to actively and intentionally break
> this use case, even though it's nonstandard at this point in time.
>
> Note that we do create flag files to prevent the clean being done
> multiple times, so the overhead of the three scripts is in reality
> very low.
I propose to re-evaluate this issue. We still call function clean_all()
three time during boot. By the way, RAMRUN no longer actually used in
any way:
$ grep -Rl RAMRUN
debian/src/initscripts/man/tmpfs.5
debian/src/initscripts/man/rcS.5
debian/initscripts.postinst
debian/changelog
debian/vars.sh
PS. Is there Debian GNU/Hurd user, who could review changes to make sure
we break nothing?
Reply to: