Re: mlocate - what is it good for?
On Wed, May 22, 2019 at 09:47:22PM +0200, Julian Andres Klode wrote: > I think mlocate only really makes sense on data storage servers with > huge disks, or on machines with HDDs. I therefore do not think the > overhead of building the index is warranted for most users. It might > make sense to keep mlocate in always-on tasks, like servers, but get > rid of it from desktop scenarios. In my early days of using Linux, I used locate dozens of times a day. I might know the filename but not the pathname, or a part of a filename, etc. "locate XF86Config" was way easier than "find / -name '*XF86Config*' -print". Sure, the find command is simpler today, but it still spews loads of useless error messages unless you also add 2> /dev/null. (And maybe you care about some but not all errors. Unlikely but possible.) Now that I'm far more familiar with where files live I no longer use locate for this purpose. Now I fall firmly in the other camp, where locate is annoyingly slow and I will try my hand at writing a replacement someday: $ time locate thisdoesntexist real1m29.294s user1m27.649s sys 0m1.644s Anyway, I believe locate can have great value to all our users, experienced or brand new, huge systems or small systems. I'd like us to keep it in default installs. Thanks signature.asc Description: PGP signature -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: mlocate - what is it good for?
I not search things all the time, but when I do I use find-pipe-grep. Not because "locate" is an inferior solution, not at all, just a matter of habit. On Wed, May 22, 2019 at 5:09 PM Andrea Corbellini < corbellini.and...@gmail.com> wrote: > On Wed, May 22, 2019 at 8:47 PM Julian Andres Klode < > julian.kl...@canonical.com> wrote: > >> On Wed, May 22, 2019 at 01:19:48PM -0600, Neal McBurnett wrote: >> > I use mlocate multiple times a day. >> > Find is way too slow and inconvenient for finding files in a big >> > set of filesystems, compared to properly configuring mlocate. >> >> Specifically, the filesystem must be huge or on a slow medium. It might >> make >> sense to move it out of standard and elsewhere, as I don't think it's >> necessarily needed everywhere, such as laptops. >> > > There's also the case of a blazing-fast medium, but high I/O load. > That's the case that I'm often facing when working on production servers. > Using find there is very frustrating. > > Consider my laptop, fairly standard, 512 GB NVME SSD, about 250G allocated, >> containing about 1435134 files. mlocate foo takes 1s, find / -mount >> -name '*foo*' takes about 7-9 secs, or 19 seconds with all mount points >> (but there is a davfs mount of an internet server, so things might be >> screwed up a bit). >> >> 19s to find something is perfectly workable, also you don't usually >> find from /, but you have an idea where things are, so it will be much >> faster. >> > > 19s for my standards are a lot, especially if I have to do multiple > searches. > There have been cases where I dumped the output of "find /" into a file > and resorted to search using grep. > > >> >> I think mlocate only really makes sense on data storage servers with >> huge disks, or on machines with HDDs. I therefore do not think the >> overhead of building the index is warranted for most users. It might >> make sense to keep mlocate in always-on tasks, like servers, but get >> rid of it from desktop scenarios. >> -- >> debian developer - deb.li/jak | jak-linux.org - free software dev >> ubuntu core developer i speak de, en >> >> -- >> ubuntu-devel mailing list >> ubuntu-de...@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >> > -- > ubuntu-devel mailing list > ubuntu-de...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- Marcos H. Alano Linux System Administrator marcoshal...@gmail.com -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: mlocate - what is it good for?
Hi Neal, On Wed, May 22, 2019 at 01:19:48PM -0600, Neal McBurnett wrote: > I use mlocate multiple times a day. > Find is way too slow and inconvenient for finding files in a big > set of filesystems, compared to properly configuring mlocate. Does "properly configuring mlocate" mean you are using something other than the default, generic config? If you are already configuring the mlocate package on your systems, it doesn't seem onerous to also have to install the package because it's not installed by default; do you agree? > It also seems that the bugs should be addressed (and have in some > cases been addressed) whether or not find is installed by default. > > Thanks, > > Neal McBurnett http://neal.mcburnett.org/ > > On Wed, May 22, 2019 at 11:59:57AM -0700, Brian Murray wrote: > > The Ubuntu Foundations team was recently looking at an issue with > > mlocate[1] and the effect it has on all users of Ubuntu. While that > > specific issue is fixable there are also issues[2,3] with keeping > > PRUNEFS and PRUNEPATHS current in updatedb.conf. So we ended up > > questioning the usefulness of installing mlocate by default on systems > > at all. We believe that find is an adequate replacement for mlocate but > > want to hear from you about use cases where it may not be. I'll start > > with a personal example: > > > > "I don't remember (because I need to know so infrequently) where the > > meta-release file is cached on disk by update-manager and use locate to > > find it. The find command itself is inadequate because the cached file > > exists in both /home and /var." > > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880507 > > [2] http://launchpad.net/bugs/827841 > > [3] http://launchpad.net/bugs/1823518 > > > > Thanks, > > -- > > Brian Murray -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
mlocate - what is it good for?
The Ubuntu Foundations team was recently looking at an issue with mlocate[1] and the effect it has on all users of Ubuntu. While that specific issue is fixable there are also issues[2,3] with keeping PRUNEFS and PRUNEPATHS current in updatedb.conf. So we ended up questioning the usefulness of installing mlocate by default on systems at all. We believe that find is an adequate replacement for mlocate but want to hear from you about use cases where it may not be. I'll start with a personal example: "I don't remember (because I need to know so infrequently) where the meta-release file is cached on disk by update-manager and use locate to find it. The find command itself is inadequate because the cached file exists in both /home and /var." [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880507 [2] http://launchpad.net/bugs/827841 [3] http://launchpad.net/bugs/1823518 Thanks, -- Brian Murray -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
[Bug 1827924] Re: Panic or segfault in Samba
This may be https://bugzilla.samba.org/show_bug.cgi?id=13315, found also in https://bugzilla.samba.org/show_bug.cgi?id=13315, but we don't even have the crash file and I can't reproduce it at the moment by just connecting using SMB1: it won't crash. ** Bug watch added: Samba Bugzilla #13315 https://bugzilla.samba.org/show_bug.cgi?id=13315 -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to samba in Ubuntu. https://bugs.launchpad.net/bugs/1827924 Title: Panic or segfault in Samba To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1827924/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: mlocate - what is it good for?
On Wed, May 22, 2019 at 8:47 PM Julian Andres Klode < julian.kl...@canonical.com> wrote: > On Wed, May 22, 2019 at 01:19:48PM -0600, Neal McBurnett wrote: > > I use mlocate multiple times a day. > > Find is way too slow and inconvenient for finding files in a big > > set of filesystems, compared to properly configuring mlocate. > > Specifically, the filesystem must be huge or on a slow medium. It might > make > sense to move it out of standard and elsewhere, as I don't think it's > necessarily needed everywhere, such as laptops. > There's also the case of a blazing-fast medium, but high I/O load. That's the case that I'm often facing when working on production servers. Using find there is very frustrating. Consider my laptop, fairly standard, 512 GB NVME SSD, about 250G allocated, > containing about 1435134 files. mlocate foo takes 1s, find / -mount > -name '*foo*' takes about 7-9 secs, or 19 seconds with all mount points > (but there is a davfs mount of an internet server, so things might be > screwed up a bit). > > 19s to find something is perfectly workable, also you don't usually > find from /, but you have an idea where things are, so it will be much > faster. > 19s for my standards are a lot, especially if I have to do multiple searches. There have been cases where I dumped the output of "find /" into a file and resorted to search using grep. > > I think mlocate only really makes sense on data storage servers with > huge disks, or on machines with HDDs. I therefore do not think the > overhead of building the index is warranted for most users. It might > make sense to keep mlocate in always-on tasks, like servers, but get > rid of it from desktop scenarios. > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en > > -- > ubuntu-devel mailing list > ubuntu-de...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
[Bug 1829822] Re: Panic or Segfault in Samba / Message comes for about a week several times a day
This may be https://bugzilla.samba.org/show_bug.cgi?id=13315, found also in https://bugzilla.samba.org/show_bug.cgi?id=13315, but we don't even have the crash file and I can't reproduce it at the moment by just connecting using SMB1: it won't crash. ** Bug watch added: Samba Bugzilla #13315 https://bugzilla.samba.org/show_bug.cgi?id=13315 -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to samba in Ubuntu. https://bugs.launchpad.net/bugs/1829822 Title: Panic or Segfault in Samba / Message comes for about a week several times a day To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1829822/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1829772] Re: The Samba 'panic action'
This may be https://bugzilla.samba.org/show_bug.cgi?id=13315, found also in https://bugzilla.samba.org/show_bug.cgi?id=13315, but we don't even have the crash file and I can't reproduce it at the moment by just connecting using SMB1: it won't crash. ** Bug watch added: Samba Bugzilla #13315 https://bugzilla.samba.org/show_bug.cgi?id=13315 -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to samba in Ubuntu. https://bugs.launchpad.net/bugs/1829772 Title: The Samba 'panic action' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1829772/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1829754] Re: Panic or segfault in Samba after migration to Ubuntu 16.04.6
This may be https://bugzilla.samba.org/show_bug.cgi?id=13315, found also in https://bugzilla.samba.org/show_bug.cgi?id=13315, but we don't even have the crash file and I can't reproduce it at the moment by just connecting using SMB1: it won't crash. ** Bug watch added: Samba Bugzilla #13315 https://bugzilla.samba.org/show_bug.cgi?id=13315 -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to samba in Ubuntu. https://bugs.launchpad.net/bugs/1829754 Title: Panic or segfault in Samba after migration to Ubuntu 16.04.6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1829754/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1829843] Re: Panic in Samba when creating session
This may be https://bugzilla.samba.org/show_bug.cgi?id=13315, found also in https://bugzilla.samba.org/show_bug.cgi?id=13315, but we don't even have the crash file and I can't reproduce it at the moment by just connecting using SMB1: it won't crash. ** Bug watch added: Samba Bugzilla #13315 https://bugzilla.samba.org/show_bug.cgi?id=13315 -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to samba in Ubuntu. https://bugs.launchpad.net/bugs/1829843 Title: Panic in Samba when creating session To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1829843/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1829916] Re: The Samba 'panic action' script, /usr/share/samba/panic-action, was called for PID 31240 (/usr/sbin/smbd). This means there was a problem with the program, such as a segfault. Below
This may be https://bugzilla.samba.org/show_bug.cgi?id=13315, found also in https://bugzilla.samba.org/show_bug.cgi?id=13315, but we don't even have the crash file and I can't reproduce it at the moment by just connecting using SMB1: it won't crash. ** Bug watch added: Samba Bugzilla #13315 https://bugzilla.samba.org/show_bug.cgi?id=13315 -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to samba in Ubuntu. https://bugs.launchpad.net/bugs/1829916 Title: The Samba 'panic action' script, /usr/share/samba/panic-action, was called for PID 31240 (/usr/sbin/smbd). This means there was a problem with the program, such as a segfault. Below is a backtrace for this process generated with gdb, which shows the state of the program at the time the error occurred. The Samba log files may contain additional information about the problem. If the problem persists, you are encouraged to first install the samba-dbg package, which contains the debugging symbols for the Samba binaries. Then submit the provided information as a bug report to Ubuntu by visiting this link: https://launchpad.net/ubuntu/+source/samba/+filebug [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 0x7f703d7f6687 in __GI___waitpid (pid=31242, stat_loc=stat_loc@entry=0x7fffb26356a8, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30 #0 0x7f703d7f6687 in __GI___waitpid (pid=31242, stat_loc=stat_loc@entry=0x7fffb26356a8, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30 #1 0x7f703d761067 in do_system (line=) at ../sysdeps/posix/system.c:149 #2 0x7f703eedaaf1 in smb_panic_s3 () from /usr/lib/x86_64-linux- gnu/libsmbconf.so.0 #3 0x7f7040fc35af in smb_panic () from /usr/lib/x86_64-linux-gnu/libsamba-util.so.0 #4 0x7f7040fc37c6 in ?? () from /usr/lib/x86_64-linux-gnu/libsamba-util.so.0 #5 #6 0x7f7040c1673b in smbXsrv_session_create () from /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0 #7 0x7f7040bacfee in reply_sesssetup_and_X () from /usr/lib/x86_64 -linux-gnu/samba/libsmbd-base.so.0 #8 0x7f7040be90ea in ?? () from /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0 #9 0x7f7040beb70e in ?? () from /usr/lib/x86_64-linux-gnu/samba /libsmbd-base.so.0 #10 0x7f7040bec61c in ?? () from /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0 #11 0x7f703db0ced0 in ?? () from /usr/lib/x86_64-linux- gnu/libtevent.so.0 #12 0x7f703db0b357 in ?? () from /usr/lib/x86_64-linux-gnu/libtevent.so.0 #13 0x7f703db077cd in _tevent_loop_once () from /usr/lib/x86_64-linux-gnu/libtevent.so.0 #14 0x7f703db079eb in tevent_common_loop_wait () from /usr/lib/x86_64 -linux-gnu/libtevent.so.0 #15 0x7f703db0b2f7 in ?? () from /usr/lib/x86_64-linux-gnu/libtevent.so.0 #16 0x7f7040bed998 in smbd_process () from /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0 #17 0x55e5c2603fcc in ?? () #18 0x7f703db0ced0 in ?? () from /usr/lib/x86_64-linux-gnu/libtevent.so.0 #19 0x7f703db0b357 in ?? () from /usr/lib/x86_64-linux-gnu/libtevent.so.0 #20 0x7f703db077cd in _tevent_loop_once () from /usr/lib/x86_64-linux- gnu/libtevent.so.0 #21 0x7f703db079eb in tevent_common_loop_wait () from /usr/lib/x86_64-linux-gnu/libtevent.so.0 #22 0x7f703db0b2f7 in ?? () from /usr/lib/x86_64-linux- gnu/libtevent.so.0 #23 0x55e5c25ff34a in main () A debugging session is active. Inferior 1 [process 31240] will be detached. Quit anyway? (y or n) [answered Y; input not from terminal] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1829916/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: mlocate - what is it good for?
Hey there, Andrea Corbellini wrote: >I personally use 'locate' all the time, and rarely use 'find' if >'locate' is available. Same here. I just plain like it better and find it more intuitive to use. I'd also like to add that, since mlocate was specifically mentioned in the subject line, I found this page on Stack Exchange, which explores the difference between locate and mlocate: https://unix.stackexchange.com/questions/273182/difference-between-locate-and-mlocate That page also links to this page in the Debian repositories, for an interesting explanation of what mlocate is and does: https://packages.debian.org/jessie/mlocate -- Little Girl There is no spoon. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: mlocate - what is it good for?
Seems to me for an individual user such as I (my laptop runs Ubuntu 18.04), locate and (the cumbersome) find are sufficient. To what extent does decision-making balance net ops and large system administrators as opposed to individual users? On 5/22/19 3:47 PM, Julian Andres Klode wrote: On Wed, May 22, 2019 at 01:19:48PM -0600, Neal McBurnett wrote: I use mlocate multiple times a day. Find is way too slow and inconvenient for finding files in a big set of filesystems, compared to properly configuring mlocate. Specifically, the filesystem must be huge or on a slow medium. It might make sense to move it out of standard and elsewhere, as I don't think it's necessarily needed everywhere, such as laptops. Consider my laptop, fairly standard, 512 GB NVME SSD, about 250G allocated, containing about 1435134 files. mlocate foo takes 1s, find / -mount -name '*foo*' takes about 7-9 secs, or 19 seconds with all mount points (but there is a davfs mount of an internet server, so things might be screwed up a bit). 19s to find something is perfectly workable, also you don't usually find from /, but you have an idea where things are, so it will be much faster. I think mlocate only really makes sense on data storage servers with huge disks, or on machines with HDDs. I therefore do not think the overhead of building the index is warranted for most users. It might make sense to keep mlocate in always-on tasks, like servers, but get rid of it from desktop scenarios. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: mlocate - what is it good for?
On Wed, May 22, 2019 at 01:19:48PM -0600, Neal McBurnett wrote: > I use mlocate multiple times a day. > Find is way too slow and inconvenient for finding files in a big > set of filesystems, compared to properly configuring mlocate. Specifically, the filesystem must be huge or on a slow medium. It might make sense to move it out of standard and elsewhere, as I don't think it's necessarily needed everywhere, such as laptops. Consider my laptop, fairly standard, 512 GB NVME SSD, about 250G allocated, containing about 1435134 files. mlocate foo takes 1s, find / -mount -name '*foo*' takes about 7-9 secs, or 19 seconds with all mount points (but there is a davfs mount of an internet server, so things might be screwed up a bit). 19s to find something is perfectly workable, also you don't usually find from /, but you have an idea where things are, so it will be much faster. I think mlocate only really makes sense on data storage servers with huge disks, or on machines with HDDs. I therefore do not think the overhead of building the index is warranted for most users. It might make sense to keep mlocate in always-on tasks, like servers, but get rid of it from desktop scenarios. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: mlocate - what is it good for?
Hi Brian, I personally use 'locate' all the time, and rarely use 'find' if 'locate' is available. The major problem I have with find is that it's slow. Even restricting the search space to a specific directory (as opposed to searching everything under "/") can be slow. For example, searching my home directory takes a while, due to the large number of Python virtual envs that I have. Sometimes searching a specific directory simply does not work with find due to the presence of symlinks. You have to wait for find to complete (which might take a while), realize that maybe symlinks are involved (which is not obvious) and re-run find with -L, hoping it will work. Searching from the root directory "/" with find is not just slow, but also clobbers the terminal with "Permission Denied" or "Operation Not Permitted" errors. You must remember to use 2>/dev/null (hoping that won't hide any useful errors). With locate instead you can search the entire filesystem and get your results in a few milliseconds, without thinking about edge cases. Also, if you want to always exclude certain filesystems or directories, with find you have to play with -prune or -xdev or similar, and repeat the same arguments every time. With locate, you can just edit one configuration file once and you're done. In my locate configuration I exclude things like my LXC/LXD containers: I never want results involving those. Those are the reasons why I wish locate was enabled everywhere, not just Ubuntu :-) Hope this helps! On Wed, May 22, 2019, 20:00 Brian Murray wrote: > The Ubuntu Foundations team was recently looking at an issue with > mlocate[1] and the effect it has on all users of Ubuntu. While that > specific issue is fixable there are also issues[2,3] with keeping > PRUNEFS and PRUNEPATHS current in updatedb.conf. So we ended up > questioning the usefulness of installing mlocate by default on systems > at all. We believe that find is an adequate replacement for mlocate but > want to hear from you about use cases where it may not be. I'll start > with a personal example: > > "I don't remember (because I need to know so infrequently) where the > meta-release file is cached on disk by update-manager and use locate to > find it. The find command itself is inadequate because the cached file > exists in both /home and /var." > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880507 > [2] http://launchpad.net/bugs/827841 > [3] http://launchpad.net/bugs/1823518 > > Thanks, > -- > Brian Murray > > -- > ubuntu-devel mailing list > ubuntu-de...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
[Bug 1823422] Re: heimdal ftbfs in disco
** Bug watch added: Debian Bug tracker #923930 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923930 ** Also affects: heimdal (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923930 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to heimdal in Ubuntu. https://bugs.launchpad.net/bugs/1823422 Title: heimdal ftbfs in disco To manage notifications about this bug go to: https://bugs.launchpad.net/heimdal/+bug/1823422/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: mlocate - what is it good for?
I use mlocate multiple times a day. Find is way too slow and inconvenient for finding files in a big set of filesystems, compared to properly configuring mlocate. It also seems that the bugs should be addressed (and have in some cases been addressed) whether or not find is installed by default. Thanks, Neal McBurnett http://neal.mcburnett.org/ On Wed, May 22, 2019 at 11:59:57AM -0700, Brian Murray wrote: > The Ubuntu Foundations team was recently looking at an issue with > mlocate[1] and the effect it has on all users of Ubuntu. While that > specific issue is fixable there are also issues[2,3] with keeping > PRUNEFS and PRUNEPATHS current in updatedb.conf. So we ended up > questioning the usefulness of installing mlocate by default on systems > at all. We believe that find is an adequate replacement for mlocate but > want to hear from you about use cases where it may not be. I'll start > with a personal example: > > "I don't remember (because I need to know so infrequently) where the > meta-release file is cached on disk by update-manager and use locate to > find it. The find command itself is inadequate because the cached file > exists in both /home and /var." > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880507 > [2] http://launchpad.net/bugs/827841 > [3] http://launchpad.net/bugs/1823518 > > Thanks, > -- > Brian Murray > > -- > ubuntu-devel mailing list > ubuntu-de...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
[Bug 1829380] Re: race condition between vhost_net_stop and CHR_EVENT_CLOSED on shutdown crashes qemu (fix regression)
This bug was fixed in the package qemu - 1:2.8+dfsg-3ubuntu2.9~cloud6 --- qemu (1:2.8+dfsg-3ubuntu2.9~cloud6) xenial-ocata; urgency=medium . * SECURITY UPDATE: Add support for exposing md-clear functionality to guests - d/p/ubuntu/enable-md-clear.patch - CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091 * SECURITY UPDATE: heap overflow when loading device tree blob - d/p/ubuntu/CVE-2018-20815.patch: specify how large the buffer to copy the device tree blob into is. - CVE-2018-20815 * SECURITY UPDATE: information leak in SLiRP - d/p/ubuntu/CVE-2019-9824.patch: check sscanf result when emulating ident. - CVE-2019-9824 * d/p/ubuntu/fix-virtio-net-regression.patch: Fix regression of failing qemu guest networking (LP: #1829380). ** Changed in: cloud-archive/ocata Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to qemu in Ubuntu. https://bugs.launchpad.net/bugs/1829380 Title: race condition between vhost_net_stop and CHR_EVENT_CLOSED on shutdown crashes qemu (fix regression) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1829380/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1829380] Update Released
The verification of the Stable Release Update for qemu has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-12126 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-12127 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-12130 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-20815 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-11091 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-9824 -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to qemu in Ubuntu. https://bugs.launchpad.net/bugs/1829380 Title: race condition between vhost_net_stop and CHR_EVENT_CLOSED on shutdown crashes qemu (fix regression) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1829380/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1829484] Re: krb5-multidev dependency broken with ESM Trusty Repo
Thanks for getting back to us! No need to be sorry. I'll mark this bug as invalid then. If new information arises that could indicate this was something else, feel free to reopen the bug. ** Changed in: krb5 (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to krb5 in Ubuntu. https://bugs.launchpad.net/bugs/1829484 Title: krb5-multidev dependency broken with ESM Trusty Repo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1829484/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
