Bug#211014: initscripts: Do not remove /var/un/brltty.pid
Miquel van Smoorenburg <miquels@cistron.nl> writes:
> On Mon, 15 Sep 2003 12:17:37, Mario Lang wrote:
>> Package: initscripts
>> Version: 2.85-7
>> Severity: minor
>> Tags: patch
>>
>> Package brltty needs to use a pid-file mechanism for
>> start-stop-daemon, since automatic restarting on upgrade is
>> no good idea for this software.
>>
>> BRLTTY also needs to be started as early as possible in the
>> boot process. Currently, it is at S25, but I'd even like
>> to have it earlier in the future.
>>
>> However, bootmisc.sh removes /var/run/brltty.pid, which
>> results in /etc/init.d/brltty stop no longer working.
>
> Yes, that is a known problem, for which noone has found
> a proper solution yet (it's also a /hard/ problem)
>
> Problem: clean /var/run as soon as it is mounted
> Complication: what if /var or /var/run is mounted
> from the network in /etc/rcS.d/ ?
Well, it seems as if the case of /var over Network is
not really very wide-spread. But I see your point.
> Also, for you to think of - what if brltty is run on a system
> which mounts /var or /var/run over the network at
> S45mountnfs.sh ? You really can't assume /var/run is
> even available at S25brltty. See also /etc/rcS.d/README.
Well, however, the FHS demands that I place pid-files in /var/run.
To clarify my point, having BRLTTY start early is really essential.
Especially before file-system checks. If your machine ever happens
to get in a state where fsck fails and demands manual interaction,
you really need Braille output to be able to fix the machine on your own.
Same is for just fs-check. It would be nice to be able to see
the progress bar, instead of having to hope for the best.
Put in other words, imagine video output only being available
after S55. I dont think you would like that.
>> Attached is a patch against bootmisc.sh which adds
>> brltty.pid to the exclude list. I think this is the
>> right way to go, since there are already two other special cases
>> (for innd and pump) there.
>
> It's the wrong way to go - the proper solution should enable us
> to get rid of the special cases, not add to it.
I can see your point. However, I can not see a obvious
solution for the problem at hand for brltty in the near future. I would need
to find a way to eihter
* Save pid-files somewhere else, which violates FHS
* Do not use pid-files at all, and find another mechanism to make
start-stop-daemon work reliably.
In any case, if you really think that no special cases
should be added, I will file another bug requesting the removal of
the currently existing special cases.
>> This is, for brltty, a fairly important bug currently.
>> So if you do not have time currently, please let me know
>> and I will do a proper NMU with this included.
>
> Please find a proper solution - brltty should not use /var/run
> before it is officially available.
>
> Perhaps brltty should include a rcS file at say S70 that does
> a "pidof brltty" and writes the result to /var/run/brltty.pid ?
Ugh, sorry, but this
1. Sounds horrible
2. Is not reliable. Since BRLTTY 3.3, brltty has several instances
(three) running. So a "pidof brltty" returns 3 PIDs. And in any case,
it sounds a lot more broken to me having to create a pid-file
twice in the boot process. After all, FHS says:
"This directory contains system information data describing the system
since it was booted. Files under this directory must be cleared
(removed or truncated as appropriate) at the beginning of the boot
process."
I dont quite think that S55 is really "at the beginning of the boot process."
> This bug should really be reassigned to brltty itself ;)
I am not sure. Currently, I still think a change to initscripts
is required to fix this problem.
Maybe cleaning up /var/run could be done earlier, if /var | /var/run
has no entry in /etc/fstab. This way, at least the standard
setup would work, and only people who want to have /var | /var/run on
NFS, would need to do further modifications to their systems.
--
CYa,
Mario | Debian Developer <URL:http://debian.org/>
| Get my public key via finger mlang@db.debian.org
| 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
Reply to: