karmic: /afs should be ready before gdm starts

Martin <email address hidden> writes:

> The use of a legacy init script in openafs-client leads to the situation
> that on boot-up, /afs is not necessary ready before the gdm screen
> starts. This is a problem because our users home directories are in
> /afs. So if I log in after boot-up there is no writable home directory
> which results in many annoying error messages. I have to switch to a
> virtual terminal, log in, become root and restart gdm then.

> Is there anything I can do to fix this issue?

I wonder if AFS should provide $remote_fs, which will force it to be
started prior to anything that declares a dependency on $remote_fs. Now
that afsd has been moved to /sbin, I think that should work properly.
Currently it wants $remote_fs started before it runs, although doesn't
require it.

Ah, yes, the problem at present is that fs is in /usr/bin, not in /bin, so
things like setting the sysname and enabling setcrypt won't work if /usr
isn't available.

I wonder if I should move fs into /bin. Hrm.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

I don't think adding those dependencies to the init script will work for Ubuntu; my understanding is that the Upstart-based boot system just runs System V-style init scripts in the traditional order after all Upstart jobs have completed.

I think to fix this in Ubuntu, we'd need to switch openafs-client over to shipping an Upstart job instead of a sysv init job.

Evan Broder <email address hidden> writes:

> I don't think adding those dependencies to the init script will work for
> Ubuntu; my understanding is that the Upstart-based boot system just runs
> System V-style init scripts in the traditional order after all Upstart
> jobs have completed.

> I think to fix this in Ubuntu, we'd need to switch openafs-client over
> to shipping an Upstart job instead of a sysv init job.

I'm happy to provide an upstart job, but since I can't include it in the
Debian package, that will probably require some sort of divergence of the
Ubuntu package from the Debian package, which will make maintenance
difficult.

I'm hoping Debian will just switch to upstart, since that would make a lot
of things simpler.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

My temporary solution for the problem is to add the following line to the "start on"-field of the /etc/init/gdm.conf:

and stopped rc RUNLEVEL=[2345]

This causes gdm to not start until all legacy System V-style init scripts finished. So booting is a little bit slower but it works.

@Russ: Can't you make different packages for ubuntu and for debian? If you already have an upstart job, can you post it here?

Martin <email address hidden> writes:

> @Russ: Can't you make different packages for ubuntu and for debian?

I don't personally use Ubuntu and have no systems available for testing,
and I'm afraid I don't have the time to do the setup, testing, and
additional packaging for more direct support of Ubuntu than I'm doing by
way of the Debian packages. I'm certainly happy to help someone else who
does have time, but I'm afraid I can't commit to doing it myself.

> If you already have an upstart job, can you post it here?

I don't -- I haven't yet looked at what would be involved. I think
upstart is conceptually a better system than init, but I haven't used it a
lot yet and don't have any experience with writing jobs for it.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

(Evan: Actually, the task of running the SysV initscripts is itself an upstart job that may run in parallel with other upstart jobs, not necessarily after them. It just happens to take the longest in practice.)

Russ: The package could detect at build time whether to use an upstart job or a SysV initscript. (This might be as simple as, say, [ -e /etc/init/mountall.conf ], but maybe there’s a better way.) That would be easier to maintain than a forked package.

Russ, if someone came up with an Upstart job, how opposed would you be
to a package that installed the sysvinit script on Debian and the
Upstart job on Ubuntu, so that we we could just sync the package from
Debian?

On Mon, Nov 30, 2009 at 3:33 PM, Russ Allbery <email address hidden> wrote:
> Martin <email address hidden> writes:
>
>> @Russ: Can't you make different packages for ubuntu and for debian?
>
> I don't personally use Ubuntu and have no systems available for testing,
> and I'm afraid I don't have the time to do the setup, testing, and
> additional packaging for more direct support of Ubuntu than I'm doing by
> way of the Debian packages.  I'm certainly happy to help someone else who
> does have time, but I'm afraid I can't commit to doing it myself.
>
>> If you already have an upstart job, can you post it here?
>
> I don't -- I haven't yet looked at what would be involved.  I think
> upstart is conceptually a better system than init, but I haven't used it a
> lot yet and don't have any experience with writing jobs for it.
>
> --
> Russ Allbery (<email address hidden>)               <http://www.eyrie.org/~eagle/>
>
> --
> karmic: /afs should be ready before gdm starts
> https://bugs.launchpad.net/bugs/483506
> You received this bug notification because you are subscribed to openafs
> in ubuntu.
>

Evan Broder <email address hidden> writes:

> Russ, if someone came up with an Upstart job, how opposed would you be
> to a package that installed the sysvinit script on Debian and the
> Upstart job on Ubuntu, so that we we could just sync the package from
> Debian?

I'd be happy to do that in theory, but in practice, I'm not sure how you
can do that with a dpkg package. Did you have an approach in mind?

I was trying to come up with a way of doing that, but nothing was coming
to mind that wasn't kind of scary (like having the package build process
determine whether it was being built on an Ubuntu or a Debian system and
building packages with different contents on that basis, which seems like
a bad idea since it will generate multiple *.deb files with the same name
and version but different contents depending on where they're built).

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

On Mon, Nov 30, 2009 at 4:01 PM, Russ Allbery <email address hidden> wrote:
> Evan Broder <email address hidden> writes:
>
>> Russ, if someone came up with an Upstart job, how opposed would you be
>> to a package that installed the sysvinit script on Debian and the
>> Upstart job on Ubuntu, so that we we could just sync the package from
>> Debian?
>
> I'd be happy to do that in theory, but in practice, I'm not sure how you
> can do that with a dpkg package.  Did you have an approach in mind?
>
> I was trying to come up with a way of doing that, but nothing was coming
> to mind that wasn't kind of scary (like having the package build process
> determine whether it was being built on an Ubuntu or a Debian system and
> building packages with different contents on that basis, which seems like
> a bad idea since it will generate multiple *.deb files with the same name
> and version but different contents depending on where they're built).

That was...basically what I was thinking of doing.

Evan Broder <email address hidden> writes:
> On Mon, Nov 30, 2009 at 4:01 PM, Russ Allbery <email address hidden> wrote:

>> I was trying to come up with a way of doing that, but nothing was
>> coming to mind that wasn't kind of scary (like having the package build
>> process determine whether it was being built on an Ubuntu or a Debian
>> system and building packages with different contents on that basis,
>> which seems like a bad idea since it will generate multiple *.deb files
>> with the same name and version but different contents depending on
>> where they're built).

> That was...basically what I was thinking of doing.

Maybe I should just do that -- I'm just worried about user confusion and
systems that are cross-installing some Debian packages and some Ubuntu
packages. Never producing multiple things with the same name and version
but different contents is one of those Packaging 101 rules that one should
generally never violate, though. Too many things assume the invariant
that any package with the same name and version is functionally identical.

I suppose another alternative would be to ship an upstart configuration
even on Debian, since it would just sit there in the upstart directory and
not do anything unless upstart was installed. Hm. Maybe I should ask
about this on debian-devel.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

To update this bug, we came away from DebConf10 with a plan for how to adapt Debian Policy to allow packages to support multiple init systems. As soon as that is finalized (post-squeeze), I will start shipping an upstart job in the openafs package in both Debian and Ubuntu and deactivate the init script if upstart is in use.

For anyone still watching this, the Debian Policy is still ongoing, so a fix for this is still pending a conclusion that would allow me to ship an upstart job in Debian.

Is this still pending Debian Policy? We just got bitten by this in Precise and are debating whether to implement a workaround and which one to implement.

Er, to be more specific, we're using LightDM, not gdm, but it's essentially the same bug: "The login screen appears before the filesystem is ready".