Some general observations on FreeBSD from a rookie coming from Linux

Normally on FreeBSD, system-wide defaults are stored in /etc and /usr/local/etc. This is straight from the Handbook. I would suggest that you spend some quality time reading it, it contains a surprising amount of useful info to get you started on a LOT of stuff.

Excellent thanks. I have been reading parts of it, but as you say it contains such a surprising amount of useful info that sometimes it is very easy to get lost in it!

If you haven't been there already: <https://freebsdfoundation.org/> in particular, yesterday's Technology Roadmap and (more generally) the Journal.


Fantastic. I have been finding as much interesting documentation as I can, I have read a few of the journal articles already, but did not see this page. Rather remarkable how much info is on here!
 
Normally on FreeBSD, system-wide defaults are stored in /etc and /usr/local/etc.
Correct, but a clean install gives you these files in the root dir, hard linked to the ones in /root. They're referenced by /etc/freebsd-update.conf and /usr/sbin/mergemaster. From the latter:
Code:
echo "   *** Historically BSD derived systems have had a"
echo "       hard link from /.cshrc and /.profile to"
echo "       their namesakes in /root.  Please indicate"
echo "       your preference below for bringing your"
echo "       installed files up to date."
So I think it's best to leave 'em there. Things like pw useradd may need them.
 
Excellent thanks. I have been reading parts of it, but as you say it contains such a surprising amount of useful info that sometimes it is very easy to get lost in it!



Fantastic. I have been finding as much interesting documentation as I can, I have read a few of the journal articles already, but did not see this page. Rather remarkable how much info is on here!
You might also find these Desktop Tutorials useful too.
 
Code:
root@throwaway:/ # bfs / -inum 28

/.cshrc
/dev/klog
/root/.cshrc
root@throwaway:/ # bfs / -inum 30

/.profile
/dev/io
/root/.profile
root@throwaway:/ # file /dev/klog

/dev/klog: character special (0/28)
root@throwaway:/ # file /dev/io

/dev/io: character special (0/30)
root@throwaway:/ # exit

… interesting, the character special devices.
 
Given the inode (number) of a file, how does a person discover the names/paths?

As indicated, you can use find(1) to search for files matching an inode number used as input. However, the combination of the device and the inode belonging to the file located on that device is unique. So you can have two files that are in your filesystem your mounted directory structure* that have the same inode number but are located on different devices. If that is the case then those two identical inode numbers represent different files. I also suspect that traversing (parts of) a large filesystem with find will not always give satisfactory results, performance wise.

The internal structure is such that the device is represented by st_dev (Numeric ID of the device containing the file) and st_ino (The file's inode number). These are part of a struct as described in stat(2); using this you could write a (e.g. C) programme that intelligently searches the internal structure of inodes. Currently FreeBSD does not have such a programme or command.

AIX does have such a command, see: istat {FileName | i-nodeNumber Device}

ls(1) gives you slightly more info how many filenames refer to the same inode:
Code:
$ ls -il /bin/tcsh /bin/csh
48635176 -r-xr-xr-x  2 root  wheel  424304 Feb  8  2021 /bin/csh
48635176 -r-xr-xr-x  2 root  wheel  424304 Feb  8  2021 /bin/tcsh

Here you see the filenames csh and tcsh refer to the same inode (=the same file). The number 2 before root is the number of links, indicating that there are exactly 2 references active to that specific inode (=48635176).

You can "increment" and "decrement" the number of links. When you create a new file and (hard) link that to an already present file on the same device via ln(1), you'll increment that number (deleting a file will decrement it). That is hard linking, as opposed to soft linking, via a symbolic link.

Code:
% touch file1 ; ls -il
total 0
34759410 -rw-r--r--  1 sox  sox  0 Sep 19 20:45 file1
% ln file1 file2 ; ls -il
total 0
34759410 -rw-r--r--  2 sox  sox  0 Sep 19 20:45 file1
34759410 -rw-r--r--  2 sox  sox  0 Sep 19 20:45 file2
% rm file1 ; ls -il
total 0
34759410 -rw-r--r--  1 sox  sox  0 Sep 19 20:45 file2

___
* edit: clarification added about files system versus directory structure.
 
… exactly 2 references active to that specific inode …

… a clean install gives you these files in the root dir, hard linked to the ones in /root. …

With the clean installation above and below, I see:
  • two regular files /.cshrc and /root/.cshrc plus one character special file for inode 28 with two links, not three
  • two regular files /.profile and /root/.profile plus one character special file for inode 30 with two links, not three
Ignoring the numbers 28 and 30, are these trios normal?

1632079374305.png
 
Compare with stat(1) and, in all likelyhood, you'll find different values for Device in the output:
$ stat -x /.cshrc
$ stat -x /dev/klog

Such trios indeed exist; for example, for me:
Code:
# find / -inum 7
/dev/console
/root/.cshrc
/.cshrc

However, they do not indicate the resemblence you might think.

___
P.S. At first I suspected that your bfs (in # bfs / -inum 28) had something to do with btrfs, clearly not correct. I think that you've defined that as an alias for some incarnation of find.
 
The presence of .profile and .cshrc in the root is a throwback to the time when the home directory of the root account was "/". It would have been required during transition to using "/root". I would be staggered if anything relied on those links today. Having said that, I leave them in place, unmolested.
 
Thanks guys some interesting discussion on those files. I noticed there are about four files in my /tmp directory on startup that have a . in front like .ICE-unix, do these serve any purpose outside of an X server?
 
Thanks, people.

… I would be staggered if anything relied on those links today. Having said that, I leave them in place, …

For what it's worth, I haven't noticed any problem since (a few weeks or months ago) I weeded the supposedly superfluous links, from my everyday environment, however this is 14.0 CURRENT.

PS, that's not to recommend removal. (The weeding was performed after comparing notes, online, with other people whose installations were without the files at the / level.)

clean installation

More accurately: I installed just one package.

Code:
root@throwaway:/ # pkg info
bfs-2.2.1                      Breadth-first version of the UNIX find command
pkg-1.16.3                     Package manager

… suspect that traversing (parts of) a large filesystem with find will not always give satisfactory results, performance wise. …

True.

My nearly clean installation of FreeBSD had no large file system but (before the pastes above) I ran both bfs(1) and find(1) with time(1), sure enough the results with bfs were (with minimal file systems) fractionally faster. From <https://github.com/tavianator/bfs#user-content-breadth-vs-depth>:

… The advantage of breadth-first over depth-first search is that it usually finds the file(s) you're looking for faster. …

sysutils/bfs
 
Hi everyone. I have used Linux since
The separation of OS and other software (pkg or ports) is great. freebsd-update is quite slow but you learn to live with it, kinda has its charm.
"Staff" on the forums are just forum mods (or admins/whatever), not associated with the FreeBSD Foundation.
You buy hardware to suit the OS, not the other way around (unless you're a developer and know how to do that stuff).
 
Thanks guys some interesting discussion on those files. I noticed there are about four files in my /tmp directory on startup that have a . in front like .ICE-unix, do these serve any purpose outside of an X server?

Code:
5.2. Socket directory ownership and permissions
The socket directories created in /tmp are now required to be owned by root and have their sticky-bit set. If the premissions are not set correctly, the component using this directory will print an error message and fail to start. Common socket directories that are known to be affected include:


/tmp/.font-unix
/tmp/.ICE-unix
/tmp/.X11-unix
These directories are used by the font server, xfs, applications using the Inter-Client Exchange protocol (ICE) and the X server, respectively.
There are several solutions to the problem of when to create these directories. They could be created at install time by the system's installer if the /tmp dir is persistent. They could be created at boot time by the system's boot scripts (e.g., the init.d scripts). Or, they could be created by PAM modules at service startup or user login time.


The solution chosen is platform dependent, and the system administrator should be able to handle creating those directories on any systems that do not have the correct ownership or permissions.

^^this info may be outdated, as it it from 2005 :-/, but yea, they are X-relevant files, you don't need to worry about them.

Do you have clear_tmp_enable="YES" in /etc/rc.conf?
 
The so-called "skeleton" files are copied when creating a new user account.

Code:
     -m            This option instructs pw to attempt to create the user's
                   home directory.  While primarily useful when adding a new
                   account with useradd, this may also be of use when moving
                   an existing user's home directory elsewhere on the file
                   system.  The new home directory is populated with the
                   contents of the skeleton directory, which typically
                   contains a set of shell configuration files that the user
                   may personalize to taste.  Files in this directory are
                   usually named dot.⟨config⟩ where the dot prefix will be
                   stripped.  When -m is used on an account with usermod,
                   existing configuration files in the user's home directory
                   are not overwritten from the skeleton files.
pw(8)


As for the order of startup scripts, that depends on the shell and how that shell is invoked.
Code:
   Startup and shutdown
       A login shell begins by executing commands from the system files
       /etc/csh.cshrc and /etc/csh.login.  It then executes commands from
       files in the user's home directory: first ~/.tcshrc (+) or, if
       ~/.tcshrc is not found, ~/.cshrc, then the contents of ~/.history (or
       the value of the histfile shell variable) are loaded into memory, then
       ~/.login, and finally ~/.cshdirs (or the value of the dirsfile shell
       variable) (+).  The shell may read /etc/csh.login before instead of
       after /etc/csh.cshrc, and ~/.login before instead of after ~/.tcshrc or
       ~/.cshrc and ~/.history, if so compiled; see the version shell
       variable. (+)

       Non-login shells read only /etc/csh.cshrc and ~/.tcshrc or ~/.cshrc on
       startup.
tcsh(1)

Code:
   Invocation
     If no arguments are present and if the standard input of the shell is
     connected to a terminal (or if the -i option is set), the shell is
     considered an interactive shell.  An interactive shell generally prompts
     before each command and handles programming and command errors
     differently (as described below).  When first starting, the shell
     inspects argument 0, and if it begins with a dash (‘-’), the shell is
     also considered a login shell.  This is normally done automatically by
     the system when the user first logs in.  A login shell first reads
     commands from the files /etc/profile and then .profile in a user's home
     directory, if they exist.  If the environment variable ENV is set on
     entry to a shell, or is set in the .profile of a login shell, the shell
     then subjects its value to parameter expansion and arithmetic expansion
     and reads commands from the named file.  Therefore, a user should place
     commands that are to be executed only at login time in the .profile file,
     and commands that are executed for every shell inside the ENV file.  The
     user can set the ENV variable to some file by placing the following line
     in the file .profile in the home directory, substituting for .shrc the
     filename desired:

           ENV=$HOME/.shrc; export ENV

     The first non-option argument specified on the command line will be
     treated as the name of a file from which to read commands (a shell
     script), and the remaining arguments are set as the positional parameters
     of the shell ($1, $2, etc.).  Otherwise, the shell reads commands from
     its standard input.

     Unlike older versions of sh the ENV script is only sourced on invocation
     of interactive shells.  This closes a well-known, and sometimes easily
     exploitable security hole related to poorly thought out ENV scripts.
sh(1)
 
Code:
5.2. Socket directory ownership and permissions
The socket directories created in /tmp are now required to be owned by root and have their sticky-bit set. If the premissions are not set correctly, the component using this directory will print an error message and fail to start. Common socket directories that are known to be affected include:


/tmp/.font-unix
/tmp/.ICE-unix
/tmp/.X11-unix
These directories are used by the font server, xfs, applications using the Inter-Client Exchange protocol (ICE) and the X server, respectively.
There are several solutions to the problem of when to create these directories. They could be created at install time by the system's installer if the /tmp dir is persistent. They could be created at boot time by the system's boot scripts (e.g., the init.d scripts). Or, they could be created by PAM modules at service startup or user login time.


The solution chosen is platform dependent, and the system administrator should be able to handle creating those directories on any systems that do not have the correct ownership or permissions.

^^this info may be outdated, as it it from 2005 :-/, but yea, they are X-relevant files, you don't need to worry about them.

Do you have clear_tmp_enable="YES" in /etc/rc.conf?
Thanks yes I have clear_tmp_enable set but did not notice them disappear, perhaps because they are hidden? Would these files be created by an xorg install if they were removed manually before doing so?
 
Would these files be created by an xorg install if they were removed manually before doing so?
No, they would not. And clear_tmp_enable actually creates them if they're missing (which would happen if you used tmpfs(5) for /tmp for example and rebooted). But it does clear /tmp of everything else. Stuff in /tmp is not guaranteed to survive a reboot (see hier(7)).
Code:
        # X related directories to create in /tmp.
        local x11_socket_dirs="${tmp}/.X11-unix ${tmp}/.XIM-unix \
                               ${tmp}/.ICE-unix ${tmp}/.font-unix"
See /etc/rc.d/cleartmp


There is a daily_clean_tmps_enable you can set in /etc/periodic.conf (it's disabled by default). And that too ignores those directories. By default, unless you modified daily_clean_tmps_ignore.
Code:
daily_clean_tmps_ignore=".X*-lock .X11-unix .ICE-unix .font-unix .XIM-unix"
daily_clean_tmps_ignore="$daily_clean_tmps_ignore quota.user quota.group .snap"
daily_clean_tmps_ignore="$daily_clean_tmps_ignore .sujournal"
 
No, they would not. And clear_tmp_enable actually creates them if they're missing (which would happen if you used tmpfs(5) for /tmp for example and rebooted). But it does clear /tmp of everything else. Stuff in /tmp is not guaranteed to survive a reboot (see hier(7)).
Code:
        # X related directories to create in /tmp.
        local x11_socket_dirs="${tmp}/.X11-unix ${tmp}/.XIM-unix \
                               ${tmp}/.ICE-unix ${tmp}/.font-unix"
See /etc/rc.d/cleartmp
I know that this is offtopic, but with a bit of technical background one just has to admire the design of this operating system. Everything is laid out plainly and simply,(almost) everything is well documented and can be easily found. Even I can read /etc/rc.d/cleartmp and understand what it does.
 
./.snap/ I cleared as it looks like it is for recovery (is that autogenerated when needed if I delete it?)
UFS file system snapshots are stored in that directory:

trev@shadow [/.snap] $ ll
total 58912
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210906040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210907040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210908040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210909040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210910040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210911040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210912040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210913040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210914040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210915040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210916040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210917040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210918040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210919040300
-r--r----- 1 root operator 3.8G 24 Sep 16:35 snapshot_20210920040300
-r--r----- 1 root operator 3.8G 24 Sep 16:35 snapshot_20210921040300
-r--r----- 1 root operator 3.8G 24 Sep 16:35 snapshot_20210922040300
-r--r----- 1 root operator 3.8G 24 Sep 16:35 snapshot_20210923040300
-r--r----- 1 root operator 3.8G 24 Sep 16:35 snapshot_20210924040300
 
Back
Top