| 2008-04-29 05:06:20 |
Lucian Adrian Grijincu |
bug |
|
|
added bug |
| 2008-04-29 05:09:09 |
Lucian Adrian Grijincu |
description |
On hardy, if you install git-daemon-run a new service is created and handled incorrectly by "runsv" and not "upstart" as all other services (#74135)
On system shutdown we ask "runsv" and "runsvdir" to terminate, but they refuse (as seen in #224041).
This refusal interacts in some weird manner with the synchronization of data on the main root partition so that on the next boot fsck needs to be run to fix errors left behind.
I tested 4 times this scenario:
* login to system
* manually kill runsv and runsvdir by repeating:
kill -9 `pidof runsv` `pidof runsvdir`
* reboot
* while booting the new system notice no file system check is needed.
And several times this one:
* login
* (don't do anything to disturb runsv, or runsvdir)
* reboot
* notice that file system checks are done and some errors appear to have been detected and fixed (fsck exits with error code 0). The system automatically reboots.
* while booting the new system notice no file system check is needed again. |
On hardy, if you install git-daemon-run a new service is created and handled incorrectly by "runsv" and not "upstart" as all other services (https://bugs.launchpad.net/ubuntu/+source/git-core/+bug/74135)
On system shutdown we ask "runsv" and "runsvdir" to terminate, but they refuse (as seen in https://bugs.launchpad.net/ubuntu/+source/git-core/+bug/224041).
This refusal interacts in some weird manner with the synchronization of data on the main root partition so that on the next boot fsck needs to be run to fix errors left behind.
I tested 4 times this scenario:
* login to system
* manually kill runsv and runsvdir by repeating:
kill -9 `pidof runsv` `pidof runsvdir`
* reboot
* while booting the new system notice no file system check is needed.
And several times this one:
* login
* (don't do anything to disturb runsv, or runsvdir)
* reboot
* notice that file system checks are done and some errors appear to have been detected and fixed (fsck exits with error code 0). The system automatically reboots.
* while booting the new system notice no file system check is needed again.
It seems that runsv's and runsvdir's are |
|
| 2008-04-30 02:07:17 |
Lucian Adrian Grijincu |
description |
On hardy, if you install git-daemon-run a new service is created and handled incorrectly by "runsv" and not "upstart" as all other services (https://bugs.launchpad.net/ubuntu/+source/git-core/+bug/74135)
On system shutdown we ask "runsv" and "runsvdir" to terminate, but they refuse (as seen in https://bugs.launchpad.net/ubuntu/+source/git-core/+bug/224041).
This refusal interacts in some weird manner with the synchronization of data on the main root partition so that on the next boot fsck needs to be run to fix errors left behind.
I tested 4 times this scenario:
* login to system
* manually kill runsv and runsvdir by repeating:
kill -9 `pidof runsv` `pidof runsvdir`
* reboot
* while booting the new system notice no file system check is needed.
And several times this one:
* login
* (don't do anything to disturb runsv, or runsvdir)
* reboot
* notice that file system checks are done and some errors appear to have been detected and fixed (fsck exits with error code 0). The system automatically reboots.
* while booting the new system notice no file system check is needed again.
It seems that runsv's and runsvdir's are |
On hardy, if you install git-daemon-run a new service is created and handled incorrectly by "runsv" and not "upstart" as all other services (https://bugs.launchpad.net/ubuntu/+source/git-core/+bug/74135)
On system shutdown we ask "runsv" and "runsvdir" to terminate, but they refuse (as seen in https://bugs.launchpad.net/ubuntu/+source/git-core/+bug/224041).
This refusal interacts in some weird manner with the synchronization of data on the main root partition so that on the next boot fsck needs to be run to fix errors left behind.
I tested 4 times this scenario:
* login to system
* manually kill runsv and runsvdir by repeating:
kill -9 `pidof runsv` `pidof runsvdir`
* reboot
* while booting the system notice no file system check is needed.
And several times this one:
* login
* (don't do anything to disturb runsv, or runsvdir)
* reboot
* notice that file system checks are done and some errors appear to have been detected and fixed (fsck exits with error code 3). The system automatically reboots.
* while booting the new system notice no file system check is needed again.
It seems that because runsv's and runsvdir's refuse to terminate some data does not get flushed to disk. |
|
| 2012-11-30 10:54:36 |
Thomas Hotz |
sysvinit (Ubuntu): status |
New |
Confirmed |
|
| 2012-11-30 10:54:42 |
Thomas Hotz |
bug |
|
|
added subscriber Thomas Hotz |
| 2013-05-17 21:27:42 |
Steve Langasek |
affects |
sysvinit (Ubuntu) |
git-core (Ubuntu) |
|
