Solved Where is that dot coming from?

nxjoseph

nxjoseph

Hi,

I don't use any GUI login manager because i'd like to see what's going on my computer and don't need bloat. I noticed a interesting dot character in the TTY log. It's not too annoying but i think it causes damage to aesthetic. Where do you think it's coming from? You can see it in the attached picture. Thanks in advance.
 

Attachments

  • PXL_20250531_114646081.jpg
    PXL_20250531_114646081.jpg
    1.6 MB · Views: 290
I have it too. I guess it's coming from some network-related service starting up in the background and then echoing a dot to the console at some stage while other services have already started.
 
bsdcode said:
I have it too. I guess it's coming from some network-related service starting up in the background and then echoing a dot to the console at some stage while other services have already started.
Click to expand...
Thanks, it's good to know that someone else is also experiencing the same issue. I hope we can finally find out what service is causing this. I might try to review the network-related scripts to see which one is echoing the dot.

ShelLuser said:
Does the dot also move? If so then I wonder if you might be running the moused service.
Click to expand...
No, I am sure that I don't use moused service because i disabled it explicitly. Also, IIRC, it would be a cursor, not a dot.

Code: 
clear_tmp_enable="YES"
syslogd_flags="-ss"
hostname="freebsd"
ifconfig_re0="SYNCDHCP"
ntpd_enable="YES"
ntpd_sync_on_start="YES"
powerd_enable="YES"
moused_nondefault_enable="NO"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
zfs_enable="YES"
kld_list="amdtemp fusefs amdgpu"
allscreens_flags="-f ProFont_r400-22.fnt -m off"
dbus_enable="YES"
nginx_enable="YES"
hydroxide_args="-disable-carddav"
hydroxide_enable="YES"
linux_enable="YES"

# grep moused_enable /etc/defaults/rc.conf
moused_enable="NO"      # Run the mouse daemon.

Thanks for answering y'all.
 
maybe a combination of the rcorder and service command gives a clue. See what gets started before dbus since the extra dot shows up there
 
mer said:
maybe a combination of the rcorder and service command gives a clue. See what gets started before dbus since the extra dot shows up there
Click to expand...
That's a nice idea! Here is the 10+10 services before and after dbus. But, unfortunately, even I did comment things like echo '.' and/or startmsg '.', i still couldn't find the one that prints that dot.

Rich (BB code): 
# rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | grep -A10 -B10 dbus
/usr/local/etc/rc.d/syncthing-relaysrv
/usr/local/etc/rc.d/poudriered
/etc/rc.d/local
/etc/rc.d/rarpd
/etc/rc.d/powerd
/etc/rc.d/ntpd
/etc/rc.d/nscd
/etc/rc.d/mountlate
/etc/rc.d/lpd
/etc/rc.d/rwho
/usr/local/etc/rc.d/dbus
/etc/rc.d/utx
/etc/rc.d/rtadvd
/etc/rc.d/sdpd
/etc/rc.d/ubthidhci
/etc/rc.d/moused
/etc/rc.d/mountd
/etc/rc.d/rfcomm_pppd_server
/etc/rc.d/bthidd
/etc/rc.d/bluetooth
/etc/rc.d/swaplate
 
This will be an excellent opportunity for some boot detective work. You've got some clues: it appears in the screen output after dbus and before the cron message. What causes the 'dbus' and 'cron' messages to appear? Can you make each of those 'go away'; will the dot still appear? Can you influence the order in which the dbus and cron messages appear (see mer 's hint): does that make the 'dot' go away? Did it move?
 
Erichans said:
This will be an excellent opportunity for some boot detective work. You've got some clues: it appears in the screen output after dbus and before the cron message. What causes the 'dbus' and 'cron' messages to appear? Can you make each of those 'go away'; will the dot still appear? Can you influence the order in which the dbus and cron messages appear (see mer 's hint): does that make the 'dot' go away? Did it move?
Click to expand...
I disabled cron & dbus services, still the dot is there. I also wonder, in the rcorder log i posted, why there isn't cron after dbus which it seems it should according to picture?
 

Attachments

  • PXL_20250531_155045773.jpg
    PXL_20250531_155045773.jpg
    1.3 MB · Views: 214
Oh, I remember that dot, though for me it was always printed over some character in the word, making me go through scripts searching for typos :D I don't remember if I figured it out or not though.
 
What recording single dot in /var/log/messages?
For example, I find, for example,
May 29 06:12:10 [myhostname] kernel: .
in mine. Others are periods at the end of sentenses, points in version strings and so on.
More, something went background as daemons could print dots without logging to /var/log/messages, and these could be asynchronous with anything started up simultaneously.

And quite wild prediction, possibly DHCP?
IIRC, I saw wpa_supplicant and/or wlan (or its undeylying driver) exposed dots while searching APs and connecting to it, but it shouldn't the case here reading your config.
 
T-Aoki said:
What recording single dot in /var/log/messages?
For example, I find, for example,
May 29 06:12:10 [myhostname] kernel: .
in mine. Others are periods at the end of sentenses, points in version strings and so on.
More, something went background as daemons could print dots without logging to /var/log/messages, and these could be asynchronous with anything started up simultaneously.

And quite wild prediction, possibly DHCP?
IIRC, I saw wpa_supplicant and/or wlan (or its undeylying driver) exposed dots while searching APs and connecting to it, but it shouldn't the case here reading your config.
Click to expand...
I couldn't see something similar in /var/log/messages.

I used static IP instead of DHCP and the result is still same but with another trouble, annoying ntpd messages trying to cover login prompt of tty:/

Code: 
May 31 17:03:01 freebsd ntpd[68946]: error resolving pool 0.freebsd.pool.ntp.org: Name does not resolve (8)
May 31 17:03:02 freebsd ntpd[68946]: error resolving pool 2.freebsd.pool.ntp.org: Name does not resolve (8)

Code: 
clear_tmp_enable="YES"
syslogd_flags="-ss"
hostname="freebsd"
ifconfig_re0="inet 192.168.1.104 netmask 255.255.255.0"
defaultrouter="192.168.1.1"
ntpd_enable="YES"
ntpd_sync_on_start="YES"
powerd_enable="YES"
moused_nondefault_enable="NO"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
zfs_enable="YES"
kld_list="amdtemp fusefs amdgpu"
allscreens_flags="-m off -f ProFont_r400-22.fnt"
dbus_enable="NO"
nginx_enable="YES"
hydroxide_args="-disable-carddav"
hydroxide_enable="YES"
linux_enable="YES"
cron_enable="NO"
 
I learnt how to only show enabled rc.d scripts and the list is now:
Code: 
% rcorder /etc/rc.d/* /usr/local/etc/rc.d/* | service -e | column
/etc/rc.d/hostid                /etc/rc.d/zfs                   /etc/rc.d/resolv                /usr/local/etc/rc.d/dbus
/etc/rc.d/zpool                 /etc/rc.d/linux                 /etc/rc.d/gptboot               /etc/rc.d/utx
/etc/rc.d/zpoolreguid           /etc/rc.d/devmatch              /etc/rc.d/os-release            /etc/rc.d/powerd
/etc/rc.d/zpoolupgrade          /etc/rc.d/cleanvar              /etc/rc.d/dmesg                 /etc/rc.d/ntpd
/etc/rc.d/zvol                  /etc/rc.d/ip6addrctl            /etc/rc.d/motd                  /usr/local/etc/rc.d/nginx
/etc/rc.d/hostid_save           /etc/rc.d/rctl                  /etc/rc.d/virecover             /usr/local/etc/rc.d/hydroxide
/etc/rc.d/kldxref               /etc/rc.d/mixer                 /etc/rc.d/newsyslog             /etc/rc.d/sendmail
/etc/rc.d/zfsbe                 /etc/rc.d/netif                 /etc/rc.d/syslogd               /etc/rc.d/cron
/etc/rc.d/var_run               /etc/rc.d/devd                  /etc/rc.d/savecore              /etc/rc.d/bgfsck

service(8)
Code: 
     -e  List services that are enabled.  The list of scripts to check is
         compiled using rcorder(8) the same way that it is done in rc(8), then
         that list of scripts is checked for an "rcvar" assignment.  If
         present the script is checked to see if it is enabled.
 
nxjoseph said:
I used static IP instead of DHCP and the result is still same but with another trouble, annoying ntpd messages :/
Click to expand...
If you're using DHCP, it would automatically set up resolver. But for static IP, it should be somehow configured elsewhere.

You don't seem to enabling local_unbound, nor any other local name server. So assuming it's not up and running.

In these cases, /etc/resolv.conf should be configured for external networks.
(If you know all IP addresses for all external hosts you need to access, of course registering everything in /etc/hosts would be sufficient, but not realistic usually.) See resolv.conf(5) for details.
 
T-Aoki said:
What recording single dot in /var/log/messages?
For example, I find, for example,
May 29 06:12:10 [myhostname] kernel: .
in mine. Others are periods at the end of sentenses, points in version strings and so on.
More, something went background as daemons could print dots without logging to /var/log/messages, and these could be asynchronous with anything started up simultaneously.

And quite wild prediction, possibly DHCP?
IIRC, I saw wpa_supplicant and/or wlan (or its undeylying driver) exposed dots while searching APs and connecting to it, but it shouldn't the case here reading your config.
Click to expand...
12345678901234567890123456789012345678
May 29 06:12:10 [myhostname] kernel: .
T-Aoki, is that a position accurate display? It might be the case that 'myhostname' has perhaps one more character than your actual hostname as the dot appears at character position 38 in your 'quoted' line.

nxjoseph, your dot in two screenshots appears at position 37 (starting from 1); does it always appear at that character position?

As T-Aoki suggests this might be output by some asynchronous process, I thought that might be the case as well. What happens with the dot if you boot single user mode?

Another variable that may help: try and see if using boot_verbose (see: loader.conf - boot_verbose) does make something change 'around' the dot. If you have it enabled, disable it, or just the other way around. If you report something about where this makes a difference, mention if it whas with boot_verbose enabled or disabled.
 
I think another question is:
Is the "dot" part of the whole rc framework, indicating a state passed?
Like rc called start_precmd, run_rc_command executed?

Take a look at /etc/rc.subr, there is at least one "echo -n ." line, perhaps tweaking that file gives insight. At the very least comment out all the "echo -n ." lines to see if it goes away.
 
Erichans said:
T-Aoki, is that a position accurate display? It might be the case that 'myhostname' has perhaps one more character than your actual hostname as the dot appears at character position 38 in your 'quoted' line.
Click to expand...
Not sure. Just looked for something printing single dot in /var/log/messages, and the host name is intentionally edited.
But on boot time, outputs from kernel can be asynchronous, so printed while something others are printing something else.
 
Erichans said:
nxjoseph, your dot in two screenshots appears at position 37 (starting from 1); does it always appear at that character position?
Click to expand...
I didn't understand this question much but, the dot did appear under above line's "kernel" word right under the "r" character, so it seems to be at same position. I don't know how you calculated the 37.

Erichans said:
As T-Aoki suggests this might be output by some asynchronous process, I thought that might be the case as well. What happens with the dot if you boot single user mode?
Click to expand...
The dot didn't appear in single-user mode.

Erichans said:
Another variable that may help: try and see if using boot_verbose (see: loader.conf - boot_verbose) does make something change 'around' the dot. If you have it enabled, disable it, or just the other way around. If you report something about where this makes a difference, mention if it whas with boot_verbose enabled or disabled.
Click to expand...
I did set this variable but it didn't print out details about where this dot come from.
 
mer said:
Take a look at /etc/rc.subr, there is at least one "echo -n ." line, perhaps tweaking that file gives insight. At the very least comment out all the "echo -n ." lines to see if it goes away.
Click to expand...
I tried commenting out all echo -n lines I could find out but the dot didn't go away, i guess it loves me too much.
 
nxjoseph said:
I didn't understand this question much but, the dot did appear under above line's "kernel" word right under the "r" character, so it seems to be at same position. I don't know how you calculated the 37.
Click to expand...
Just as you said 'right under the "r"'; that 'r' ( and the dot) is at character position 37, counted from the start of the line.
 
Erichans said:
Just as you said 'right under the "r"'; that 'r' ( and the dot) is at character position 37, counted from the start of the line.
Click to expand...
I see, thanks for explaining.

mer said:
It's Immortal.
Click to expand...
:D Indeed.

mer said:
The big hammer approach would be to look at all service files for "echo -n ." commands and comment them out.
Click to expand...
Yeah, but that would take a lot time to do manually, maybe it would be easier with sed(1) but i think there is a possibility of breaking the scripts.
 
Where did you go, my little friend?

I don't know how it just gone, i don't think i did made any changes to rc.d scripts :confused:🤔

Code: 
yusuf@freebsd ~/Downloads/base/etc % diff rc.subr /etc/rc.subr
yusuf@freebsd ~/Downloads/base/etc % diff rc.d /etc/rc.d
yusuf@freebsd ~/Downloads/base/etc %
 

Attachments

  • PXL_20250601_102319211.jpg
    PXL_20250601_102319211.jpg
    1.2 MB · Views: 188
Interesting. Maybe it's just playing hide and seek?
I'm guessing timing of some sort. Some services have dependencies and get started after the ones they need, others have no dependencies and a bunch can be started together, something takes a while and then finishes and the dot appears.
Think about DHCP: maybe it takes a while for the client to get a response, so the dot shows up in the middle of something else. Then something changes the response comes quicker and the dot shows up earlier/normally.
I'm just using DHCP as an example, not as the cause.
 
mer said:
Maybe it's just playing hide and seek?
Click to expand...
Maybe :D

mer said:
Think about DHCP: maybe it takes a while for the client to get a response, so the dot shows up in the middle of something else. Then something changes the response comes quicker and the dot shows up earlier/normally.
I'm just using DHCP as an example, not as the cause.
Click to expand...
I thought that it wouldn't be from the DHCP service because I have SYNCDHCP set in /etc/rc.conf instead of just DHCP. I removed the SYNC prefix so that it wouldn't hang other services and make them wait but still the dot is missing.
 
You must log in or register to reply here.
Back
Top