Determining which process needs to be restarted after update
Hello everyone, I personally really like OpenSuSE command which is: zypper ps What it does is it lists all processes that have files opened that currently don't exist (i.e. link count is 0). This helps tremendously in determining which processes need to be restarted after an update. Is there something similar for FreeBSD? I was thinking of using lsof +L1, but on FreeBSD that command is not capable of displaying names of files that were deleted, many entries returned are for example processes that have open sockets. It also does not list names of the deleted/replaced files. Is there a tool that is capable to do such task, or maybe some additional options to lsof? I'm not too familiar with it myself. -- Best regards, Derek mailto:tak...@takeda.tk -- Look out for #1. Don't step in #2 either. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: Deleting the top-level ZFS file system (without affecting its children)
> Why would rm -rf /oldroot/* not return all the allocated space? > I can only think of snapshots keeping the space allocated, but > you can remove those too. Can you elaborate on that? Ronald, This will free space in the file system (as shown by df), but it won't return the space to the pool. It looks like ZFS won't let you shrink file systems yet. Best wishes, Matthew -- I FIGHT FOR THE USERS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Deleting the top-level ZFS file system (without affecting its children)
Hello xenophon+freebsd, Saturday, January 12, 2013, 12:47:25 PM, you wrote: >> Why would rm -rf /oldroot/* not return all the allocated space? >> I can only think of snapshots keeping the space allocated, but >> you can remove those too. Can you elaborate on that? > This will free space in the file system (as shown by df), but it won't > return the space to the pool. It looks like ZFS won't let you shrink > file systems yet. As far as I understand your question - yes it will return the space. Unless you explicitly told ZFS to reserve specific amount of space it takes as much space as given filesystems currently needs. There's no expanding/shrinking in ZFS because ZFS filesystems are not partitioning the disk in the general meaning of that word. The ZFS filesystems behave in a very similar way to directories. -- Best regards, Derekmailto:tak...@takeda.tk -- Press any key... no, no, no, NOT THAT ONE! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Determining which process needs to be restarted after update
Quoth Derek Kulinski : > > I personally really like OpenSuSE command which is: zypper ps > What it does is it lists all processes that have files opened that > currently don't exist (i.e. link count is 0). This helps tremendously > in determining which processes need to be restarted after an update. > > Is there something similar for FreeBSD? I was thinking of using > lsof +L1, but on FreeBSD that command is not capable of displaying > names of files that were deleted, many entries returned are for > example processes that have open sockets. It also does not list names > of the deleted/replaced files. > > Is there a tool that is capable to do such task, or maybe some > additional options to lsof? I'm not too familiar with it myself. procstat -fa, look for entries with 'v' in the 'T' column and '-' in the 'NAME' column (or get awk to look for you). You may also want to check the 'V' column: see the manpage for the codes. This won't tell you what the file used to be called before it was deleted: I don't think the kernel keeps that information. Ben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Determining which process needs to be restarted after update
On Sat, Jan 12, 2013 at 11:29:14PM +, Ben Morrow wrote: > Quoth Derek Kulinski : > > > > I personally really like OpenSuSE command which is: zypper ps > > What it does is it lists all processes that have files opened that > > currently don't exist (i.e. link count is 0). This helps tremendously > > in determining which processes need to be restarted after an update. > > > > Is there something similar for FreeBSD? I was thinking of using > > lsof +L1, but on FreeBSD that command is not capable of displaying > > names of files that were deleted, many entries returned are for > > example processes that have open sockets. It also does not list names > > of the deleted/replaced files. > > > > Is there a tool that is capable to do such task, or maybe some > > additional options to lsof? I'm not too familiar with it myself. > > procstat -fa, look for entries with 'v' in the 'T' column and '-' in the > 'NAME' column (or get awk to look for you). You may also want to check > the 'V' column: see the manpage for the codes. This won't tell you what > the file used to be called before it was deleted: I don't think the > kernel keeps that information. > This has at least 2 problems: - it will not show shared libraries (-v is required) - it will report processes with open unlinked files, which is completely normal But even if we use -v, I don't think we can reliably distinguish "regular" unlinked file mapping from shared library mapping (for unlinked files we will get - as a name, just like in -f case). I didn't dig into this though. Instead I would go upwards in package dependency tree and for each daemon check if it is running (should be doable without much hackery). Checking for all binaries may be more problematic. -- Mateusz Guzik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Determining which process needs to be restarted after update
Quoth Mateusz Guzik : > On Sat, Jan 12, 2013 at 11:29:14PM +, Ben Morrow wrote: > > Quoth Derek Kulinski : > > > > > > I personally really like OpenSuSE command which is: zypper ps > > > What it does is it lists all processes that have files opened that > > > currently don't exist (i.e. link count is 0). This helps tremendously > > > in determining which processes need to be restarted after an update. > > > > > > Is there something similar for FreeBSD? I was thinking of using > > > lsof +L1, but on FreeBSD that command is not capable of displaying > > > names of files that were deleted, many entries returned are for > > > example processes that have open sockets. It also does not list names > > > of the deleted/replaced files. > > > > > > Is there a tool that is capable to do such task, or maybe some > > > additional options to lsof? I'm not too familiar with it myself. > > > > procstat -fa, look for entries with 'v' in the 'T' column and '-' in the > > 'NAME' column (or get awk to look for you). You may also want to check > > the 'V' column: see the manpage for the codes. This won't tell you what > > the file used to be called before it was deleted: I don't think the > > kernel keeps that information. > > > > This has at least 2 problems: > - it will not show shared libraries (-v is required) That's a good point. > - it will report processes with open unlinked files, which is completely > normal Isn't that exactly what the OP wants to find? I agree that it happens for reasons other than a software update, but I don't see how that can be avoided. Presumably the SuSE tool mentioned would give the same false positives. > But even if we use -v, I don't think we can reliably distinguish > "regular" unlinked file mapping from shared library mapping (for > unlinked files we will get - as a name, just like in -f case). I didn't > dig into this though. A process currently running an unlinked shared library will have at least one procstat -v entry with 'x' in the 'PRT' column, 'vn' in the 'TP' column and nothing in the 'PATH' column. > Instead I would go upwards in package dependency tree and for each daemon > check if it is running (should be doable without much hackery). Checking > for all binaries may be more problematic. Yes, something like that might be better, though that will also get a lot of false positives. Ben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Some new hardware with 9.1 does not reboot easily
Hello, Willem Jan Withagen wrote: > >A reboot work around that works for me: > reboot -n > shutdown -n now >Of which the manual pages say: option should not be used. >But I have not yet found bad effects. Perhaps becuase I only have ZFS >fs-systems Thanks for the workaround! But as you said, it doesn't feel very safe... Julian -- Sent from Kaiten Mail. Please excuse my brevity. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
