[Touch-packages] [Bug 1646233] Re: file command incorrectly identifies a gzipped file as being a Minix filesystem
Maybe related. http://mx.gw.com/pipermail/file/2013/001244.html -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to file in Ubuntu. https://bugs.launchpad.net/bugs/1646233 Title: file command incorrectly identifies a gzipped file as being a Minix filesystem Status in file package in Ubuntu: New Bug description: In Ubuntu 14.04, the command `file` (1:5.14-2ubuntu3.3) incorrectly identifies a gzipped file as being a Minix filesystem. Example: ``` $ file gzip-minix.eml gzip-minix.eml: Minix filesystem, V3, 43470 zones $ file -v file-5.14 magic file from /etc/magic:/usr/share/misc/magic ``` The workaround I'm using is passing the `-k` (keep going) param to file. ``` $ file -k gzip-minix.eml gzip-minix.eml: Minix filesystem, V3, 43470 zones\012- gzip compressed data, from Unix ``` In Ubuntu 16.04, however, the file is correctly identified. ``` $ file gzip-minix.eml gzip-minix.eml: gzip compressed data, from Unix $ file -v file-5.25 magic file from /etc/magic:/usr/share/misc/magic ``` This bug has a description very similar to those reported in these URLs: - https://bugzilla.redhat.com/show_bug.cgi?id=873997 - https://bugzilla.redhat.com/show_bug.cgi?id=758429 However, despite the very similar description, I didn't find any problem with the JPEG files attached in these bug reports. Note: The error is occurring in about 1 gzipped file for each 6 or 10 files I have in my data filesystem. Because some of these files contain sensitive information, I'm attaching only one of them (an innocent example). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/file/+bug/1646233/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1646233] [NEW] file command incorrectly identifies a gzipped file as being a Minix filesystem
Public bug reported: In Ubuntu 14.04, the command `file` (1:5.14-2ubuntu3.3) incorrectly identifies a gzipped file as being a Minix filesystem. Example: ``` $ file gzip-minix.eml gzip-minix.eml: Minix filesystem, V3, 43470 zones $ file -v file-5.14 magic file from /etc/magic:/usr/share/misc/magic ``` The workaround I'm using is passing the `-k` (keep going) param to file. ``` $ file -k gzip-minix.eml gzip-minix.eml: Minix filesystem, V3, 43470 zones\012- gzip compressed data, from Unix ``` In Ubuntu 16.04, however, the file is correctly identified. ``` $ file gzip-minix.eml gzip-minix.eml: gzip compressed data, from Unix $ file -v file-5.25 magic file from /etc/magic:/usr/share/misc/magic ``` This bug has a description very similar to those reported in these URLs: - https://bugzilla.redhat.com/show_bug.cgi?id=873997 - https://bugzilla.redhat.com/show_bug.cgi?id=758429 However, despite the very similar description, I didn't find any problem with the JPEG files attached in these bug reports. Note: The error is occurring in about 1 gzipped file for each 6 or 10 files I have in my data filesystem. Because some of these files contain sensitive information, I'm attaching only one of them (an innocent example). ** Affects: file (Ubuntu) Importance: Undecided Status: New ** Attachment added: "gzip-minix.eml" https://bugs.launchpad.net/bugs/1646233/+attachment/4785419/+files/gzip-minix.eml -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to file in Ubuntu. https://bugs.launchpad.net/bugs/1646233 Title: file command incorrectly identifies a gzipped file as being a Minix filesystem Status in file package in Ubuntu: New Bug description: In Ubuntu 14.04, the command `file` (1:5.14-2ubuntu3.3) incorrectly identifies a gzipped file as being a Minix filesystem. Example: ``` $ file gzip-minix.eml gzip-minix.eml: Minix filesystem, V3, 43470 zones $ file -v file-5.14 magic file from /etc/magic:/usr/share/misc/magic ``` The workaround I'm using is passing the `-k` (keep going) param to file. ``` $ file -k gzip-minix.eml gzip-minix.eml: Minix filesystem, V3, 43470 zones\012- gzip compressed data, from Unix ``` In Ubuntu 16.04, however, the file is correctly identified. ``` $ file gzip-minix.eml gzip-minix.eml: gzip compressed data, from Unix $ file -v file-5.25 magic file from /etc/magic:/usr/share/misc/magic ``` This bug has a description very similar to those reported in these URLs: - https://bugzilla.redhat.com/show_bug.cgi?id=873997 - https://bugzilla.redhat.com/show_bug.cgi?id=758429 However, despite the very similar description, I didn't find any problem with the JPEG files attached in these bug reports. Note: The error is occurring in about 1 gzipped file for each 6 or 10 files I have in my data filesystem. Because some of these files contain sensitive information, I'm attaching only one of them (an innocent example). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/file/+bug/1646233/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1465386] Re: Default values for WAIT_STATE are wrong in the upstart wait-for-state job
Hi, I'm sorry for don't response these questions in the last months. However, in the last days, I had some time and I understood better the situation. I'll split my post in three parts. 1 - Technical background 1.1 - Lack of documentation The `wait-for-start` job is not documented. Because of this, it's more difficult to understand what should be its expected behavior. See: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/962047 1.2 - Upstart job states According do the Upstart Cookbook: > States are exposed to users via the status field in the output of the initctl status command See: http://upstart.ubuntu.com/cookbook/#job-states `waiting` and `running` are the two most common states of a job (they are the initial and final states after running the `initctl start` command). There are other ones (intermediate states), like the `running` and `starting` states. Notes: `started` and `stopped` are not job states (they are events, but not states). So, running `initctl status` will never print the `started` or `stopped` strings. 1.3 - `wait-for-state.conf` uses `started`/`stopped` as the default expected states I don't know if it's a buggy behavior or if it's intentional. In the code of the `wait-for-state.conf` file, we have: ``` env WAIT_STATE="started" env TARGET_GOAL="start" [...] if [ "$WAIT_STATE" = "stopped" ] ; then TARGET_GOAL="stop" fi ``` And `WAIT_STATE` is used in this line: ``` # Already running/stopped? status $WAIT_FOR | grep -q "$TARGET_GOAL/$WAIT_STATE" && exit 0 ``` 1.4 - Test case - Apport So, if we use (for example) `WAIT_FOR=apport` and keep the default `TARGET_GOAL`/`WAIT_STATE` values, wait-for-state will not return true when apport is already started. If apport is stopped: ``` $ stop apport apport stop/waiting $ time start wait-for-state WAIT_FOR=apport WAITER=apport wait-for-state stop/waiting real0m0.035s user0m0.000s sys0m0.006s $ echo $? 0 $ status apport apport start/running $ time start wait-for-state WAIT_FOR=apport WAITER=apport start: Job failed to start real0m30.019s user0m0.000s sys0m0.004s $ echo $? 1 ``` This is because wait-for-start grep's for "start/started" instead of "start/running". However, if we explicitly pass WAIT_STATE=running, it will work!!! ``` $ status apport apport start/running $ time start wait-for-state WAIT_FOR=apport WAITER=apport WAIT_STATE=running wait-for-state stop/waiting real0m0.018s user0m0.000s sys 0m0.004s $ echo $? 0 ``` This is because I think the default values should be `running`/`waiting` instead of `started`/`stopped`. So the code would be idempotent (it will return 0, even if the job was already started). 2 - Nova compute, GlusterFS and plymouth-shutdown cases The `nova-compute.conf` job (`nova-compute` package from `deb http ://ubuntu-cloud.archive.canonical.com/ubuntu trusty-updates/kilo main`) has the following lines in their `pre-start script` stanza: ``` # If libvirt-bin is installed, always wait for it to start first if status libvirt-bin; then start wait-for-state WAIT_FOR=libvirt-bin WAIT_STATE=running WAITER=nova-compute fi ``` Because they explicitly pass `WAIT_STATE=running`, this will always work (even if libvirt-bin is already started). In the `mounting-glusterfs.conf` job (`glusterfs-client` package from Ubuntu), they don't pass `WAIT_STATE=running`. They run: ``` start wait-for-state WAIT_FOR=static-network-up WAITER=mounting-glusterfs-$MOUNTPOINT ``` And this is buggy. Our final case will be the `plymouth-shutdown.conf` job. They run: ``` start wait-for-state WAITER=plymouth-shutdown WAIT_FOR=lightdm TARGET_GOAL=stop WAIT_STATE=waiting ``` It is, the `WAIT_STATE=waiting` var is explicitly set. Because of this, if we run the above code, it will always work, even if the lightdm daemon is already stopped. Excepting the glusterfs job, all job that I know explicitly pass the `WAIT_STATE` param (`running` or `waiting`) and do not use the default provided by the wait-for-state.conf job (`started`/`stopped`). 3 - Risks of updating wait-for-state Some Upstart scripts use wait-for-state. In my case, I know `nova- compute.conf`, `mounting-glusterf.conf`, `plymouth-shutdown.conf` and `rc.conf` (the most risky case). I use the patched version (with `running`/`waiting` values as default) in several production servers and, until nowdays, everything is fine. 4 - My opinion Ubuntu 16.04 uses systemd. Upstart will be discontinued (I liked it so much, but migrating to systemd was a good/inteligent decision). So, I think the current behavior of the wait-for-state script could be kept. The important thing here is to document the bug (unexpected behavior, not idempotent behavior). So other users can find useful information if the current behavior is confusing them. - Document the bug/behavior (we're doing this here) - Keep the current source code (it is not worth assuming the risk of a update). -- You received t
[Touch-packages] [Bug 1465386] Re: Default values for WAIT_STATE are wrong in the upstart wait-for-state job
Of course.
I actually only know two examples:
- mounting-glusterfs.conf: The glusterfs-client package uses the command
"wait-for-state WAIT_FOR=static-network-up WAITER=mounting-glusterfs" without
passing "WAIT_STATE=running";
- So, this command doesn't works;
- See: https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1465382 and
https://bugzilla.redhat.com/show_bug.cgi?id=1231983;
- nova-compute.conf: The nova-compute package uses the comand wait-for-
state, but passes the WAIT_STATE=running option ("running", in my
opinion, should be the default instead of "started"):
# If libvirt-bin is installed, always wait for it to start first
if status libvirt-bin; then
start wait-for-state WAIT_FOR=libvirt-bin WAIT_STATE=running
WAITER=nova-compute
fi
So, it works.
Again, in the link http://upstart.ubuntu.com/cookbook/#job-states, we
can sse that 'start/running' and 'stop/waiting' are the correct states,
and not the 'start/started' and 'stop/stopped'.
** Bug watch added: Red Hat Bugzilla #1231983
https://bugzilla.redhat.com/show_bug.cgi?id=1231983
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to upstart in Ubuntu.
https://bugs.launchpad.net/bugs/1465386
Title:
Default values for WAIT_STATE are wrong in the upstart wait-for-state
job
Status in upstart package in Ubuntu:
Incomplete
Bug description:
In Ubuntu 14.04, the wait-for-state job uses the env vars
WAIT_STATE="started" or WAIT_STATE="stopped". if the GOAL env var is
set to 'start' or 'stop'.
However, according to the upstart cookbook, the desired states for a
already started/stopped job are 'start/running' and 'stop/waiting'.
Maybe a misunderstood has occurred was the meaning of signals was job
states (for example, after a job reaches the start/running state, it
emits the started signal).
The strange thing is that the waiting/running wait states were
proposed at the first implementations of this job, and not the
stopped/started states: https://lists.ubuntu.com/archives/upstart-
devel/2011-February/001405.html.
This bug can make some developers to write upstart jobs that return
errors (like the GlusterFS developers, that forgot the
WAIT_STATE="running" condition).
References:
- http://upstart.ubuntu.com/cookbook/#job-states
- http://upstart.ubuntu.com/cookbook/#events-not-states
- https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1465382
I'm attaching a patch too.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1465386/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1465386] [NEW] Default values for WAIT_STATE are wrong in the upstart wait-for-state job
Public bug reported: In Ubuntu 14.04, the wait-for-state job uses the env vars WAIT_STATE="started" or WAIT_STATE="stopped". if the GOAL env var is set to 'start' or 'stop'. However, according to the upstart cookbook, the desired states for a already started/stopped job are 'start/running' and 'stop/waiting'. Maybe a misunderstood has occurred was the meaning of signals was job states (for example, after a job reaches the start/running state, it emits the started signal). The strange thing is that the waiting/running wait states were proposed at the first implementations of this job, and not the stopped/started states: https://lists.ubuntu.com/archives/upstart- devel/2011-February/001405.html. This bug can make some developers to write upstart jobs that return errors (like the GlusterFS developers, that forgot the WAIT_STATE="running" condition). References: - http://upstart.ubuntu.com/cookbook/#job-states - http://upstart.ubuntu.com/cookbook/#events-not-states - https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1465382 I'm attaching a patch too. ** Affects: upstart (Ubuntu) Importance: Undecided Status: New ** Patch added: "wait-for-state.conf.patch" https://bugs.launchpad.net/bugs/1465386/+attachment/4415275/+files/wait-for-state.conf.patch ** Summary changed: - Default values for WAIT_STATE in the upstart wait-for-state job are wrong + Default values for WAIT_STATE are wrong in the upstart wait-for-state job ** Package changed: glusterfs (Ubuntu) => upstart (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upstart in Ubuntu. https://bugs.launchpad.net/bugs/1465386 Title: Default values for WAIT_STATE are wrong in the upstart wait-for-state job Status in upstart package in Ubuntu: New Bug description: In Ubuntu 14.04, the wait-for-state job uses the env vars WAIT_STATE="started" or WAIT_STATE="stopped". if the GOAL env var is set to 'start' or 'stop'. However, according to the upstart cookbook, the desired states for a already started/stopped job are 'start/running' and 'stop/waiting'. Maybe a misunderstood has occurred was the meaning of signals was job states (for example, after a job reaches the start/running state, it emits the started signal). The strange thing is that the waiting/running wait states were proposed at the first implementations of this job, and not the stopped/started states: https://lists.ubuntu.com/archives/upstart- devel/2011-February/001405.html. This bug can make some developers to write upstart jobs that return errors (like the GlusterFS developers, that forgot the WAIT_STATE="running" condition). References: - http://upstart.ubuntu.com/cookbook/#job-states - http://upstart.ubuntu.com/cookbook/#events-not-states - https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1465382 I'm attaching a patch too. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1465386/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1465382] Re: Upstart job mounting-glusterfs.conf increases unnecessary 30 seconds in Ubuntu boot
I made an error when choosing the package. Please ignore the upstart
package and consider only the glusterfs package.
** Package changed: upstart (Ubuntu) => ubuntu
** No longer affects: ubuntu
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to upstart in Ubuntu.
https://bugs.launchpad.net/bugs/1465382
Title:
Upstart job mounting-glusterfs.conf increases unnecessary 30 seconds
in Ubuntu boot
Status in glusterfs package in Ubuntu:
New
Bug description:
**Note:** This bug is already reported at upstream. However, as it
occurs only in Ubuntu, I thought it makes sense to report it here
again. So, if the upstream team do not merge the patch (they are
mostly developers from Red Hat and may prioritize problems that affect
RedHat like OSes), the Ubuntu team can test it, merge it and propose
it to the upstream team.
See: https://bugzilla.redhat.com/show_bug.cgi?id=1231983
Description of problem:
A bug in the mounting-glusterfs.conf file increases unnecessary 30
seconds in the boot in an Ubuntu Server.
The following error is logged in /var/log/upstart/mounting-
gluster-*.log: "start: Job failed to start".
The following error is also logged in /var/log/upstart/wait-for-state-
mounting-glusterfs-*.log:
"status: Unknown job: static-network-up
start: Unknown job: static-network-up".
For last, another error ("Mount failed") is logged in
/var/log/boot.log too.
When not using the nobootwait/nofail flags in fstab, the bug can hang
the mount process (and the boot process too). When using the
nobootwait/nofail flags, the bug will increase the boot time in about
30 seconds.
Another report from another GlusterFS user can be found at [this
link](http://serverfault.com/questions/611462/glusterfs-failing-to-
mount-at-boot-with-ubuntu-14-04).
The bug is caused by the following errors:
- There is no need to wait for the network is up. The Ubuntu itself has the
_netdev mount flag that will retry the mount for each time that an interface
brings up;
- However, it's necessary to wait for the GlusterFS Server daemon (for mounts
using localhost);
- This was implemented in an old commit
([c3bbf6](https://github.com/gluster/glusterfs/commit/c3bbf6aa6c090fd066ab0079aa1c8ae332309d2a)),
more precisely in [this
link](https://github.com/gluster/glusterfs/blob/c3bbf6aa6c090fd066ab0079aa1c8ae332309d2a/extras/Ubuntu/mounting-glusterfs.conf).
However, this commit was overwritten;
- It's wrong to use the wait-for-state upstart task to wait for a signal.
It's used to wait for a job. static-network-up is an event signal, and not a
job;
- This is why the "Unknown job: static-network-up" is logged;
- It's wrong, when waiting for a job to be started, not passing the
'WAIT_STATE=running' env var because it's not the default in wait-for-state.
Version-Release number of selected component (if applicable):
Master branch (mainline, commit
https://github.com/gluster/glusterfs/commit/5cdbbf34e31758071f597561aa8572cedd56aece)
and the glusterfs-server and glusterfs-client packages in Ubuntu 14.04
(maybe the packages in other Ubuntu versions too).
How reproducible:
Every system boot.
Steps to Reproduce:
1. Create a valid volume in a Gluster Server
2. Create an entry in the /etc/fstab file in a Ubuntu 14.04 like:
gluster1:/dir /var/dir glusterfs defaults,nobootwait,nofail,_netdev 0 0
3. Reboot the system
4. Run 'mount' and check that the volume was mounted
5. Check the boot and upstart logs that shows the problem
To see more easily this problem, it's also possible:
1. Create a valid volume in a Gluster Server
2. Create an entry in the /etc/fstab file in a Ubuntu 14.04 like:
gluster1:/dir /var/dir glusterfs defaults,nobootwait,nofail,_netdev 0 0
3. Run 'time start mountall'
4. Run 'mount' and check that the volume was mounted
5. Check the upstart logs and the high value time output (about 30 seconds).
Actual results:
Errors logged and 30 seconds of unnecessary waiting.
Expected results:
The volume mounted as long as the desired interface is up (_netdev)
and the gluster daemon (if it exists) is up, without errors being
logged.
Additional info:
The files that need to be updated are
[README.Ubuntu](https://github.com/gluster/glusterfs/commits/master/extras/Ubuntu/README.Ubuntu)
and [mounting-
glusterfs.conf](https://github.com/gluster/glusterfs/blob/master/extras/Ubuntu
/mounting-glusterfs.conf).
A fixed version of 'mounting-glusterfs.conf' will be attached to this
bug report.
---
Attachment: https://bugzilla.redhat.com/attachment.cgi?id=1039191
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1465382/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.n
[Touch-packages] [Bug 1465382] [NEW] Upstart job mounting-glusterfs.conf increases unnecessary 30 seconds in Ubuntu boot
Public bug reported:
**Note:** This bug is already reported at upstream. However, as it
occurs only in Ubuntu, I thought it makes sense to report it here again.
So, if the upstream team do not merge the patch (they are mostly
developers from Red Hat and may prioritize problems that affect RedHat
like OSes), the Ubuntu team can test it, merge it and propose it to the
upstream team.
See: https://bugzilla.redhat.com/show_bug.cgi?id=1231983
Description of problem:
A bug in the mounting-glusterfs.conf file increases unnecessary 30
seconds in the boot in an Ubuntu Server.
The following error is logged in /var/log/upstart/mounting-
gluster-*.log: "start: Job failed to start".
The following error is also logged in /var/log/upstart/wait-for-state-
mounting-glusterfs-*.log:
"status: Unknown job: static-network-up
start: Unknown job: static-network-up".
For last, another error ("Mount failed") is logged in /var/log/boot.log
too.
When not using the nobootwait/nofail flags in fstab, the bug can hang
the mount process (and the boot process too). When using the
nobootwait/nofail flags, the bug will increase the boot time in about 30
seconds.
Another report from another GlusterFS user can be found at [this
link](http://serverfault.com/questions/611462/glusterfs-failing-to-
mount-at-boot-with-ubuntu-14-04).
The bug is caused by the following errors:
- There is no need to wait for the network is up. The Ubuntu itself has the
_netdev mount flag that will retry the mount for each time that an interface
brings up;
- However, it's necessary to wait for the GlusterFS Server daemon (for mounts
using localhost);
- This was implemented in an old commit
([c3bbf6](https://github.com/gluster/glusterfs/commit/c3bbf6aa6c090fd066ab0079aa1c8ae332309d2a)),
more precisely in [this
link](https://github.com/gluster/glusterfs/blob/c3bbf6aa6c090fd066ab0079aa1c8ae332309d2a/extras/Ubuntu/mounting-glusterfs.conf).
However, this commit was overwritten;
- It's wrong to use the wait-for-state upstart task to wait for a signal. It's
used to wait for a job. static-network-up is an event signal, and not a job;
- This is why the "Unknown job: static-network-up" is logged;
- It's wrong, when waiting for a job to be started, not passing the
'WAIT_STATE=running' env var because it's not the default in wait-for-state.
Version-Release number of selected component (if applicable):
Master branch (mainline, commit
https://github.com/gluster/glusterfs/commit/5cdbbf34e31758071f597561aa8572cedd56aece)
and the glusterfs-server and glusterfs-client packages in Ubuntu 14.04
(maybe the packages in other Ubuntu versions too).
How reproducible:
Every system boot.
Steps to Reproduce:
1. Create a valid volume in a Gluster Server
2. Create an entry in the /etc/fstab file in a Ubuntu 14.04 like:
gluster1:/dir /var/dir glusterfs defaults,nobootwait,nofail,_netdev 0 0
3. Reboot the system
4. Run 'mount' and check that the volume was mounted
5. Check the boot and upstart logs that shows the problem
To see more easily this problem, it's also possible:
1. Create a valid volume in a Gluster Server
2. Create an entry in the /etc/fstab file in a Ubuntu 14.04 like:
gluster1:/dir /var/dir glusterfs defaults,nobootwait,nofail,_netdev 0 0
3. Run 'time start mountall'
4. Run 'mount' and check that the volume was mounted
5. Check the upstart logs and the high value time output (about 30 seconds).
Actual results:
Errors logged and 30 seconds of unnecessary waiting.
Expected results:
The volume mounted as long as the desired interface is up (_netdev) and
the gluster daemon (if it exists) is up, without errors being logged.
Additional info:
The files that need to be updated are
[README.Ubuntu](https://github.com/gluster/glusterfs/commits/master/extras/Ubuntu/README.Ubuntu)
and [mounting-
glusterfs.conf](https://github.com/gluster/glusterfs/blob/master/extras/Ubuntu
/mounting-glusterfs.conf).
A fixed version of 'mounting-glusterfs.conf' will be attached to this
bug report.
---
Attachment: https://bugzilla.redhat.com/attachment.cgi?id=1039191
** Affects: glusterfs (Ubuntu)
Importance: Undecided
Status: New
** Also affects: glusterfs (Ubuntu)
Importance: Undecided
Status: New
** Changed in: upstart (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to upstart in Ubuntu.
https://bugs.launchpad.net/bugs/1465382
Title:
Upstart job mounting-glusterfs.conf increases unnecessary 30 seconds
in Ubuntu boot
Status in glusterfs package in Ubuntu:
New
Bug description:
**Note:** This bug is already reported at upstream. However, as it
occurs only in Ubuntu, I thought it makes sense to report it here
again. So, if the upstream team do not merge the patch (they are
mostly developers from Red Hat and may prioritize problems that affect
RedHat like OSes), the Ubuntu team can test it, me
[Touch-packages] [Bug 962047] Re: document wait-for-state
This is not a bug. It's a feature. However, it's a desired feature. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upstart in Ubuntu. https://bugs.launchpad.net/bugs/962047 Title: document wait-for-state Status in upstart package in Ubuntu: Confirmed Bug description: /etc/init/wait-for-state.conf should be documented both in a man page and in the Upstart Cookbook. Documentation should include a few examples of usage and explanation as to why this job is required currently. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/962047/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 50437] Re: Resume from hibernation may fail because swap partition UUID does not match /etc/initramfs-tools/conf.d/resume
The workaround in post 35 (https://bugs.launchpad.net/ubuntu/+source /initramfs-tools/+bug/50437/comments/35) works, but there's a more simple workaround to get the same result: 1) Update your /etc/fstab with your new SWAP partition (or partitions); 2) /var/lib/dpkg/info/initramfs-tools.preinst install 3) update-initramfs -k all -u The only improvement is in step 2. The proposed command automatically updates the UUID of the RESUME var. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/50437 Title: Resume from hibernation may fail because swap partition UUID does not match /etc/initramfs-tools/conf.d/resume Status in initramfs-tools package in Ubuntu: Triaged Status in ubiquity package in Ubuntu: Invalid Status in Baltix GNU/Linux: Confirmed Bug description: There are a variety of circumstances which can cause the swap partition UUID to get out of sync with the system configuration, for example: 1. User edits /etc/fstab to specify a different swap partition, either by UUID or by hardcoding the device path 2. User reinitializes their swap partition with a new UUID using mkswap 3. User repartitions their disk and thereby reinitializes the swap partition with a new UUID If this happens, the system will fail to resume from hibernation because it continues to look for the swap partition as specified in /etc/initramfs-tools/conf.d/resume. Not finding this device, it will continue with normal system startup, as if no hibernation had taken place. It would be better if the system were more robust in the face of such changes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/50437/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 987027] Re: command halt does not turn off computer
*** This bug is a duplicate of bug 991997 *** https://bugs.launchpad.net/bugs/991997 ** This bug is no longer a duplicate of bug 880240 system doesn't turn off if "sudo halt" is given ** This bug has been marked a duplicate of bug 991997 Wrong comment in /etc/default/halt: Default behavior of "halt" changed to halt only instead of powering off -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upstart in Ubuntu. https://bugs.launchpad.net/bugs/987027 Title: command halt does not turn off computer Status in upstart package in Ubuntu: Confirmed Bug description: command halt does not turn off computer. This command correctly close all linux comand, sessions etc...but does not turn off computer. Thanks for your help. LGDN ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: upstart 1.5-0ubuntu5 ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14 Uname: Linux 3.2.0-23-generic i686 ApportVersion: 2.0.1-0ubuntu5 Architecture: i386 Date: Sun Apr 22 23:58:37 2012 InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha i386 (20110302) SourcePackage: upstart UpgradeStatus: Upgraded to precise on 2012-02-02 (79 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/987027/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 880240] Re: system doesn't turn off if "sudo halt" is given
*** This bug is a duplicate of bug 991997 *** https://bugs.launchpad.net/bugs/991997 Hi, I think the current behavior is correctly, but the comment in "/etc/default/halt" sould be updated. So, I proposed a patch in https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/991997/comments/6 (a related bug). ** This bug has been marked a duplicate of bug 991997 Wrong comment in /etc/default/halt: Default behavior of "halt" changed to halt only instead of powering off -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upstart in Ubuntu. https://bugs.launchpad.net/bugs/880240 Title: system doesn't turn off if "sudo halt" is given Status in upstart package in Ubuntu: Won't Fix Bug description: Since I upgraded from 11.04 to 11.10 the system doesn't turn off at the end of halt procedure if it's called via commandline (local or remote shell) . At some point of halt procedure the system freezes and all I can do is turning off pc via physical power button and halting it using GUI or via "sudo shutdown -h now" , these two methods work flawlessly. I have this problem on both x86_64 and x86. Anyway if I shut down the pc using ligthdm or unity the system is turned off properly. Description: Ubuntu 11.10 Release: 11.10 Linux travelmate 3.0.0-13-generic #21-Ubuntu SMP Mon Oct 17 20:18:09 UTC 2011 i686 i686 i386 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/880240/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 883705] Re: 11.10 will not power off laptop
*** This bug is a duplicate of bug 991997 *** https://bugs.launchpad.net/bugs/991997 ** This bug is no longer a duplicate of bug 880240 system doesn't turn off if "sudo halt" is given ** This bug has been marked a duplicate of bug 991997 Wrong comment in /etc/default/halt: Default behavior of "halt" changed to halt only instead of powering off -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upstart in Ubuntu. https://bugs.launchpad.net/bugs/883705 Title: 11.10 will not power off laptop Status in upstart package in Ubuntu: Confirmed Bug description: I installed 64 bit desktop version of Ubuntu 11.10 with Unity - activated additional drivers (Broadcomm STA Wireless and ATI/AMD FGLRX Video drivers). Configured Firefox and thunderbird and then installed printer driver. When I come to shutdown the laptop I get the Ubuntu logo with the 5 dots (which should colour in as it shuts down), but nothing else happens.. I have left it for 10 mins and still nothing - no HDD activity or anything. The only way to shutdown / reboot is via holding the power button. Laptop is a HP 6735S - 4 GB RAM, 300GB HDD. Any ideas on how to identify / solve this? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/883705/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 781367] Re: system hangs on shutdown
*** This bug is a duplicate of bug 991997 *** https://bugs.launchpad.net/bugs/991997 ** This bug is no longer a duplicate of bug 880240 system doesn't turn off if "sudo halt" is given ** This bug has been marked a duplicate of bug 991997 Wrong comment in /etc/default/halt: Default behavior of "halt" changed to halt only instead of powering off -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upstart in Ubuntu. https://bugs.launchpad.net/bugs/781367 Title: system hangs on shutdown Status in upstart package in Ubuntu: Confirmed Bug description: Binary package hint: upstart In Xubuntu 11.04 command "shutdown" hangs the system. Commands "reboot" and "poweroff" when used with --force option work well. In previous version of Xubuntu (10.10) shutdown worked well. ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: upstart 0.9.7-1 ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2 Uname: Linux 2.6.38-8-generic x86_64 Architecture: amd64 Date: Thu May 12 00:20:31 2011 InstallationMedia: Xubuntu 11.04 "Natty Narwhal" - Release amd64 (20110426.1) ProcEnviron: LANGUAGE=ru_RU:en LANG=ru_RU.UTF-8 SHELL=/bin/bash SourcePackage: upstart UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/781367/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 885560] Re: Cannot shutdown 11.10 from Unity Ubuntu I installed 32 bit desktop version of Ubuntu 11.10 with Unity - activated updated drivers.Everything works well, Configured Fi
*** This bug is a duplicate of bug 991997 *** https://bugs.launchpad.net/bugs/991997 ** This bug is no longer a duplicate of bug 880240 system doesn't turn off if "sudo halt" is given ** This bug has been marked a duplicate of bug 991997 Wrong comment in /etc/default/halt: Default behavior of "halt" changed to halt only instead of powering off -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upstart in Ubuntu. https://bugs.launchpad.net/bugs/885560 Title: Cannot shutdown 11.10 from Unity Ubuntu I installed 32 bit desktop version of Ubuntu 11.10 with Unity - activated updated drivers.Everything works well, Configured Firefox and thunderbird and then installed printer driver. BUT!!! When I come to shutdown the PC I get the plain black screen , but nothing else happens..I have left it for 10 mins and still nothing - no HDD activity or anything. The only way to shutdown / reboot is via holding the power button. Any ideas on how to identify / solve this? Status in upstart package in Ubuntu: New Bug description: Cannot shutdown 11.10 from Unity Any ideas on how to identify / solve this? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/885560/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 991997] Re: Wrong comment in /etc/default/halt: Default behavior of "halt" changed to halt only instead of powering off
I think the current behavior is correctly, but the comment in "/etc/default/halt" sould be updated. Currently, this file is only used by /sbin/shutdown (or by the /etc/init.d/halt, that can be called by the /sbin/shutdown depending of the situation). Updating the comment may avoid user misunderstands. In Trusty, this file is packaged in the "initscripts" package: http://packages.ubuntu.com/trusty/amd64/initscripts/filelist The default file should be: # Default behaviour of shutdown -h. Set to "halt" or "poweroff". HALT=poweroff I'm attaching a patch to the current "initscripts" package. ** Patch added: "bug_halt_outdated_docs.patch" https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/991997/+attachment/4327304/+files/bug_halt_outdated_docs.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sysvinit in Ubuntu. https://bugs.launchpad.net/bugs/991997 Title: Wrong comment in /etc/default/halt: Default behavior of "halt" changed to halt only instead of powering off Status in sysvinit package in Ubuntu: Confirmed Status in upstart package in Ubuntu: Invalid Bug description: Hi, I just installed 12.04 and running "sudo halt" only halts the system instead of powering it off. This worked fine on 10.04 - running "halt" by itself powered off the machine and it looks like it is still configured to poweroff the box in /etc/default/halt in Precise but that doesn't happen. Is this the intended behavior? If so, is it documented somewhere? I saw a comment here: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/880240/comments/4 That said that halt no longer powers off the system, but I have been unable to find any documention explaining the change. Thanks, Charles ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: upstart 1.5-0ubuntu5 ProcVersionSignature: Ubuntu 3.2.0-24.37-generic 3.2.14 Uname: Linux 3.2.0-24-generic x86_64 NonfreeKernelModules: rr26xx ApportVersion: 2.0.1-0ubuntu7 Architecture: amd64 Date: Mon Apr 30 07:48:35 2012 InstallationMedia: Ubuntu-Server 12.04 LTS "Precise Pangolin" - Release amd64 (20120424.1) ProcEnviron: TERM=xterm LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: upstart UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/991997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
