[Bug 171054] Re: PDF better under "Export" than "Save As"
The initial report here concerned the implicit action of "Save as" which is: and make all subsequent "Save" operations also write to this file and then discussion spun off into "Export" and a wholesale rearrangement of "Save" and "Save as...". Current versions of Inkscape have "Save a copy..." in the file menu , which is nothing but "Save as.." without this implicit action. So why is this bug still open? End users can already achieve the desired result by selecting that other file menu option. If this is still considered an issue, would not a bit of text in the "Save as.." dialog, warning the user, not suffice? Perhaps place it below "Title" and have it say: This file will also be the new target for "Save". To retain the current "Save" target cancel this dialog and use "Save a Copy" instead. Alternatively, put in a check box, normally checked, that says: Make this the new target for "Save" If it was deselected, then "Save as..." would act like "Save a copy" does now. The latter change pretty much eliminates the need for a "Save a copy" file menu option, at the expense of an occasional extra mouse click within the "Save as..." dialog. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/171054 Title: PDF better under "Export" than "Save As" To manage notifications about this bug go to: https://bugs.launchpad.net/inkscape/+bug/171054/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 168164] Re: font sizes specified in pixels instead of points
There are some rounding errors in the font size display in r11664. Open the attached example file. 18.2pt is 22.75 px in the XML editor, but 18.1999 (plus or minus a few 9's) in the display. The fix would be for the bit of code that is displaying the point size, wherever that is, to do this: font_size = round (1000.0 * font_size)/1000.0; Or 1. It loses a bit of precision, but are there any applications that need 1/1th of a px font size precision? In any case 18.1 -> 18.200 and would then display as 18.2. ** Attachment added: "point_size.svg" https://bugs.launchpad.net/inkscape/+bug/168164/+attachment/3315200/+files/point_size.svg -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/168164 Title: font sizes specified in pixels instead of points To manage notifications about this bug go to: https://bugs.launchpad.net/inkscape/+bug/168164/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 168164] Re: font sizes specified in pixels instead of points
Font size in the GUI should be displayed in whichever units the user wants, with the default being points and not pixels, as that is what 99% of all drawing programs use. However, there is no reason that the internal font size cannot remain in px. It only takes a tiny bit of GUI related code to convert from pt to px (or em to px), and that will not affect any other part of the program. That should resolve the (minor) usage issue without introducing any new issues. (My current solution is to do it outside the program - I have a conversion table of points<->pixels on a sheet of paper. Not very elegant, the program should do this simple conversion.) Regarding the lack of a defined SVG viewBox, that is a separate issue and should be in its own thread. Inkscape should not let such things default to "whatever the reading program wants", as, in my experience, it is inevitable that some program will use an incompatible default. (Example: EMF import of lines with zero width - Inkscape has invisible lines, but some other programs show lines with the minimum visible width.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/168164 Title: font sizes specified in pixels instead of points To manage notifications about this bug go to: https://bugs.launchpad.net/inkscape/+bug/168164/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 505188]
Created attachment 55744 Screen shot, only example at 90 degrees is incorrect. Two more observations. 1. With LOImpress 3.5.0b2 made an odp with text at 89,90, and 91 degrees. Saved as .ppt Opened in PowerPoint 2003. Result: Only the text at 90 degrees is flipped, +/- one degree away is good enough to avoid the problem. (See the screen snap). Previous result showed that +/- 45 degrees also not a problem. Suggests that problem is most likely restricted to multiples of 90 degrees. 2. OpenOffice DEV300m106 does not have this problem when it saves to .ppt, rotated text stays at the angle it was set to in OOImpress. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/505188 Title: [Upstream] Impress mis-rotates text saving to .pptx To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/505188/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 505188]
Created attachment 55747 Test .ppt and mangled result 1. mangle.ppt is the original drawing created in PPT 2003 2. open mangle.ppt in LOImpress 3.5.0b2 3. add one word to the slide, outside the diagram 4. save as mangle2.ppt 5. exit LOImpress 6. Open mangle2.ppt in LOImpress or PPT 2003 Result: some of the text which was originally horizontal has rotated to vertical. 3.4.4 release does exactly the same thing. I just went through a .ppt file I had been using to import .pdf (as a way of converting SVG drawings) which had been repeatedly opened in LOImpress 3.4.4. There were numerous examples of mangled diagrams, mostly text originally rotated by 90 degrees now at -90 degrees, and a few cases where the rotation was completely lost (not shown). Some of them were really awful, with text drawn mirrored, possibly the result of multiple cycles of .ppt open/save in LOImpress. (I have not yet reproduced that problem.) Conclusion: it is unsafe to open a .ppt drawing in LOImpress and save it again in that same format. The only safe way to convert (from PDF) through LO is to create a fresh .ppt for each diagram imported and then later move the contents of that .ppt into the main .ppt within Microsoft PowerPoint. The "easy" method, doing that conversion in the complete .ppt opened in LOImpress, results in earlier slides being mangled by later .ppt saves. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/505188 Title: [Upstream] Impress mis-rotates text saving to .pptx To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/505188/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 505188]
Attempted to change importance to medium/normal from lowest/trivial. Not sure if that will take or not. This is not a trivial problem - it offers the possibility for LOImpress to corrupt otherwise valid .ppt/.pptx files by just opening and saving them. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/505188 Title: [Upstream] Impress mis-rotates text saving to .pptx To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/505188/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 505188]
Created attachment 55702 Example ODP, text about every 45 degrees 3.5.0b2 all tests on Windows XP SP3 1. made an example rotations2.odp with text close to every 45 degrees (manual rotation, so not exactly at that multiple). 2. save as rotations2.ppt 3. open a fresh copy of rotations2.odp, save as rotations2.ppt2 Results: 4. rotations2.ppt text orientation incorrect for 90 and 180 degrees, all others OK. (Could be a coincidence it is right for one of the multiples of 90). File opens OK in MS PowerPoint 2003 and has the same text orientations as in LOImpress. 5. rotations2.pptx file will not open with either PowerPoint 2003 (with 2007 extensions) or PowerPoint 2010. 6. rotations2.pptx opens with 3.5.0b2 LOImpress with all text orientations at 0 degrees. (All text rotation information has been lost). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/505188 Title: [Upstream] Impress mis-rotates text saving to .pptx To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/505188/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 505188]
Created attachment 55697 example of saved .ppt viewed in PowerPoint 2003. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/505188 Title: [Upstream] Impress mis-rotates text saving to .pptx To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/505188/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 505188]
Ran test on 3.5.0b2 on Windows XP SP3. The result of exporting to .pptx is that the rotations are lost. Moreover, Powerpoint 2003 (with the 2007 filters installed) could not open the file. The result of export to .ppt is complex. When viewed in LOImpress 3.5.0b2 the ppt file looks like: "Text rotated 90" is at -90 "Text rotated 180" is at 90 when viewed in Powerpoint 2003 "Text rotated 90" is at -90 "Text rotated 180" is at 0 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/505188 Title: [Upstream] Impress mis-rotates text saving to .pptx To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/505188/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 474956] Re: odg export still doesn't work
** Attachment added: "Example exported to ODG format" https://bugs.launchpad.net/inkscape/+bug/474956/+attachment/2632162/+files/bounding_line4.odg -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/474956 Title: odg export still doesn't work To manage notifications about this bug go to: https://bugs.launchpad.net/inkscape/+bug/474956/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 474956] Re: odg export still doesn't work
Problem 4, on the "open circle" type of ellipse, bottom row near the bottom/left of the diagram, the objects are not filled. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/474956 Title: odg export still doesn't work To manage notifications about this bug go to: https://bugs.launchpad.net/inkscape/+bug/474956/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 474956] Re: odg export still doesn't work
Here is a test file showing a variety of problems in Inkscape 0.48.2-1 when exporting to ODG and then read into LODraw 3.4.4. 1. Line widths are lost (show as 0.0 pts in LODraw). 2. Opacity, gradient, and pattern fills are lost 3. Ends of polylines are joined (see the triangles along the top, they should be "L" The conversion of square corners to rounded ones is an LODraw bug, it affects other imports too, including from PDF. ** Attachment added: "Example SVG" https://bugs.launchpad.net/inkscape/+bug/474956/+attachment/2632161/+files/bounding_line4.svg -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/474956 Title: odg export still doesn't work To manage notifications about this bug go to: https://bugs.launchpad.net/inkscape/+bug/474956/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 474956] Re: odg export still doesn't work
** Attachment added: "odg file seen in LODraw, sreenshot" https://bugs.launchpad.net/inkscape/+bug/474956/+attachment/2632171/+files/bounding_line4_odg_screencapture.PNG ** Bug watch added: freedesktop.org Bugzilla #43806 https://bugs.freedesktop.org/show_bug.cgi?id=43806 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/474956 Title: odg export still doesn't work To manage notifications about this bug go to: https://bugs.launchpad.net/inkscape/+bug/474956/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 474956] Re: odg export still doesn't work
Link to bug report on LODraw concerning the rounded corners problem (for PDF, but mentioned that it is common) https://bugs.freedesktop.org/show_bug.cgi?id=43806 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/474956 Title: odg export still doesn't work To manage notifications about this bug go to: https://bugs.launchpad.net/inkscape/+bug/474956/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 474956] Re: odg export still doesn't work
The filled open bezier issue (problem 4) probably needs a fix something along these lines: 1. Draw a second bezier curve identical to the first except that it is closed and the stroke is not visible. 2. Fill the second bezier curve with the fill properties from the original Inkscape SVG object. 3. Draw the primary bezier curve over it. Do not close this Bezier, do not fill it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/474956 Title: odg export still doesn't work To manage notifications about this bug go to: https://bugs.launchpad.net/inkscape/+bug/474956/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 525154] Re: mountall for /var races with rpc.statd
Regarding #58, while I agree in principle with much of what you say the underlying problem on my systems, as described in the 2nd paragraph in #55 is that rpc.statd can enter a state where it seems to be working, but actually isn't. (The only way out is to force rpc.statd to restart.) Consequently it is hard to imagine what sort of upstart syntax could possibly be used to avoid the subsequent failed NFS mounts. This is almost by definition an rpc.statd bug since no matter what upstart might or might not have done to start rpc.statd incorrectly (too early for instance), rpc.statd should be able to determine if it is, or isn't, working properly, and exit with a failed status in the latter case. -- mountall for /var races with rpc.statd https://bugs.launchpad.net/bugs/525154 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 525154] Re: mountall for /var races with rpc.statd
In another limitation of upstart, or at least upstart is most likely responsible, the "recovery mode" boot hangs when in the /etc/fstab shown in #55 either /dev/sda6 is corrupt or there are network problems and the NFS mounts are not available. I guess using Mandriva spoiled me, because there booting "failsafe" resulted in the init being bright enough to start only the barest minimum of the operating system. Mandriva (and presumably RedHat and CentOS) come up when networks are broken and partitions (other than /boot and /) are screwed up. Not so Ubuntu - it tries to mount everything in /etc/fstab even when "single" is passed as a kernel option. Moreover, due to upstart's parallel nature, it isn't entirely clear at what point it is locking - it might not even be directly after the failed mount warnings, that might indirectly break something else. Perhaps there is some other Ubuntu/upstart specific kernel option to invoke a more low level boot, but if there is, that raises the question why it was not employed by the "recovery mode" boot option Ubuntu created at installation. -- mountall for /var races with rpc.statd https://bugs.launchpad.net/bugs/525154 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 525154] Re: mountall for /var races with rpc.statd
The changes in #8 did not work for me. /var is not mounted, it is just
part of /, so the upstart's "mounted" test cannot be applied.
The strangest thing about this whole mess is that, at least in my hands,
rpc.statd can be in a state where to all outward appearances it is
running normally ("status statd" shows "start/running" and "rpcinfo -p"
shows both ports), yet until it is restarted (server statd stop; server
statd start) mountall will never respond to a SIGUSR1 from within an
init script, or (sometimes) an "at" job; yet mountall will always
respond to that signal from root in a terminal! Moreover, in this
strange state if root in a terminal enters "mount /mnt/safserver/u1" it
will result in all NFS mounts being made, not just that one.
Rarely I also see in /var/log/boot.log
mount.nfs: DNS resolution failed for safserver: Name or service not
known
This is just wrong because nsswitch.conf has "files" first for hosts,
and safserver is in /etc/hosts. Probably yet another race condition.
This one is definitely not persistent since (even without my fix)
logging in after a failed NFS mount DNS is always working.
Just discovered that the order of the lines in /etc/fstab also seems to
make a difference:
This one fails the most (every one of 4 boots):
proc/proc procnodev,noexec,nosuid 0 0
LABEL=root / ext3errors=remount-ro 0 1
LABEL=boot /boot ext3defaults0 2
LABEL=swap noneswapsw 0 0
/dev/fd0/media/floppy0 autorw,user,noauto,exec,utf8 0 0
safserver:/u4/pdb /mnt/safserver/pdb nfs ro,bg,hard,intr 0 0
safserver:/u1 /mnt/safserver/u1 nfs rw,bg,hard,intr 0 0
/dev/sda1 /mnt/windows/C ntfs-3g ro 0 0
/dev/sda6 /mnt/windows/D ntfs-3g defaults 0 0
This one fails the least (none of 4 boots):
proc/proc procnodev,noexec,nosuid 0 0
LABEL=root / ext3errors=remount-ro 0 1
LABEL=boot /boot ext3defaults0 2
LABEL=swap noneswapsw 0 0
/dev/fd0/media/floppy0 autorw,user,noauto,exec,utf8 0 0
/dev/sda1 /mnt/windows/C ntfs-3g ro 0 0
/dev/sda6 /mnt/windows/D ntfs-3g defaults 0 0
safserver:/u4/pdb /mnt/safserver/pdb nfs ro,bg,hard,intr 0 0
safserver:/u1 /mnt/safserver/u1 nfs rw,bg,hard,intr 0 0
This one is in between (fails about 75% of the time):
proc/proc procnodev,noexec,nosuid 0 0
LABEL=root / ext3errors=remount-ro 0 1
LABEL=boot /boot ext3defaults0 2
LABEL=swap noneswapsw 0 0
/dev/fd0/media/floppy0 autorw,user,noauto,exec,utf8 0 0
/dev/sda1 /mnt/windows/C ntfs-3g ro 0 0
safserver:/u4/pdb /mnt/safserver/pdb nfs ro,bg,hard,intr 0 0
safserver:/u1 /mnt/safserver/u1 nfs rw,bg,hard,intr 0 0
/dev/sda6 /mnt/windows/D ntfs-3g defaults 0 0
Suggests that the ntfs-3g mounts provide enough of a delay so that the
race condition between statd starting and nfs mounting is overcome.
(Mostly, surely in enough boots it would fail even in the best order.)
Upstart has far too many mysteries and hidden variables for my taste!
--
mountall for /var races with rpc.statd
https://bugs.launchpad.net/bugs/525154
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 525154] Re: mountall for /var races with rpc.statd
see previous comment ** Attachment added: "saf2.sh" https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/525154/+attachment/1520757/+files/saf2.sh -- mountall for /var races with rpc.statd https://bugs.launchpad.net/bugs/525154 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 525154] Re: mountall for /var races with rpc.statd
see previous coment ** Attachment added: "rc.local" https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/525154/+attachment/1520756/+files/rc.local -- mountall for /var races with rpc.statd https://bugs.launchpad.net/bugs/525154 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 525154] Re: mountall for /var races with rpc.statd
After 5 more reboots the at method failed. More exploration showed that status statd could show "start/running" and rpcinfo -p | grep status could show both the tcp and udp ports, and a couple of wait seconds could be put in there, and it could be run from an at command and even then killall -SIGUSR1 mountall would sometimes fail to respond to the signal. So I figured that perhaps statd was in a funky state too. Reset all the /etc/init files to their original values and put in rc.local and saf2.sh (the next two attachments). Have now booted 10 consecutive times with NSF mounts connected once I login.Of these 8 still had the statd error messages, but at least this hack finally made them mount in the end. Here is what shows up in the message.log when this happens: Aug 26 09:54:30 saf04 logger: NFSGLITCH marunning [ root 391 1 0 09:54 ?00:00:00 mountall --daemon ] Aug 26 09:54:30 saf04 logger: NFSGLITCH use at to kill mountall Aug 26 09:54:31 saf04 logger: NFSGLITCH2 statd: CLAIMS to be in start/running, restart it anyway Aug 26 09:54:32 saf04 logger: NFSGLITCH2 marunning? [ root 391 1 1 09:54 ?00:00:00 mountall --daemon ] Aug 26 09:54:32 saf04 logger: NFSGLITCH2 trying sigusr1 on mountall from at job Aug 26 09:54:32 saf04 kernel: [ 20.298991] RPC: Registered udp transport module. Aug 26 09:54:32 saf04 kernel: [ 20.298994] RPC: Registered tcp transport module. Aug 26 09:54:32 saf04 kernel: [ 20.298995] RPC: Registered tcp NFSv4.1 backchannel transport module. Aug 26 09:54:33 saf04 logger: NFSGLITCH2 kstat 0 marunning STILL? [ ] -- mountall for /var races with rpc.statd https://bugs.launchpad.net/bugs/525154 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 525154] Re: mountall for /var races with rpc.statd
I think it is finally working, but what a mess. Observations; 1. An explicit nfs mount like: mount /mnt/server/directory will not work from within rc.local while mountall is still running as a daemon. 2. An explicit killall -SIGUSR1 mountall from within rc.local will be ignored by mountall. 3. An explict killall -9 mountall will kill mountall, but then init goes nuts and throws up one of these General error mounting filesystems A maintenance shell will now be started etc. It does this even after one has already logged in on the console! 4. An explicit killall -SIGUSR1 mountall from a console session will allow the NFS mount to proceed, but of course that can only be done by root, and so it isn't a general solution for the end users 5. An explicit killall -SIGUSR1 mountall from an at job will also allow NFS mounts to complete. 6. I have no idea why mountall is hanging around and not starting the NFS connection. This is not a race condition with statd, as it can be tested and shown to be running while mountall is still twiddling its metaphorical fingers. So my "final" solution, until somebody fixes mountall, is to add to /etc/rc.local set +e # else any failed grep causes an exit marunning=`ps -ef | grep mountall | grep -v grep` logger "MATHOG marunning [ $marunning ]" set -e if [ -n "$marunning" ] then logger "MATHOG use at to kill mountall" at -f /etc/saf2.sh now else logger "MATHOG ma not running, no kill needed" fi Create the at file "saf2.sh" like: cat >/etc/saf2.sh
[Bug 525154] Re: mountall for /var races with rpc.statd
On my system /var is not in a separate partition, but I still have the infamous statd error messages on nfs mounts. Ubuntu 10.04.1 LTS mountall 2.15 upstart.6.5-6 I tried a bunch of things so far and none have worked reliably to cure it: 1. put a "sleep 2" in /etc/mountall-net.conf to allow time for rpc.statd to start. 2. put in two different tests in /etc/init/statd.conf to make sure statd was working before it left that script - neither worked. One was by Andrew Edmunds from bug 610863. Then this one, which verifies the expected ports are open: post-start script while [ true ] do pcount=$(rpcinfo -p 2>/dev/null | grep -c ' status$' 2>/dev/null) if [ "$pcount" == 2 ] then break; else sleep 0.1 fi done end script 3. added --debug to the kernel boot line in grub. With messages spewing every which way I sometimes see the statd warning messages but in 7 tries it never came up without the NFS volumes mounted. Of course it took much longer to boot this way, and it looks to a naive user like the system has failed, so it is not acceptable for a production system. 4. added to /etc/rc.local service statd start killall -SIGUSR1 mountall Amazingly I have since rebooted a couple of times with (just) the /etc/rc.local change in place and while it helped, it sometimes came up not only with the infamous statd error messages from the failed nfs mounts, but with mountall still running! That looks to me like upstart (which perhaps should have been named "upchuck") blew up and NEVER EVEN RAN rc.local. Either that or mountall ignored the USR1 signal. Both are really appalling possibilities in software which is supposed to be used in production environments. Heck, for all I know both failures may be present. Assuming at least one of the fixes from (2) above worked as intended then mountall is starting before the statd.conf script should have allowed it to. At least, that's the case if the post-start script must complete as a precondition of a successful statd start. If that isn't true, then what stanza should be used instead? -- mountall for /var races with rpc.statd https://bugs.launchpad.net/bugs/525154 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
