Why in FreeBSD, despite changing the settings in the daemon, the system sometimes uses either the old settings or mixes them up.

LkderS4KGc2bFd63rM

LkderS4KGc2bFd63rM

I have been observing for some time that if;,The operating system works for some time, then there is a problem with changing the settings. I noticed this in Daemon, IPFW but it also happens in other daemons. Despite changing the settings, the operating system sometimes uses the previous setting or mixes it up. I guess the problem is in the source code, but where?
 
You are doing something wrong. Changing settings and making changes stick works.
What you are doing wrong is hard to tell; you are painting a broad picture with only vague details.
 
Yeah, there's definitely something wrong. Do you use ZFS? Maybe you keep loading an older boot environment?
 
One can set sysctls by hand, such as
sysctl -w kern.sched.affinity=1

But if you reboot the system you lose that setting. If you want it to become permanent you need to edit /etc/sysctls.conf.

One can dynamically add rules to IPFW, but those changes are lost unless you add them to the correct config file.
 
I don't use LiveCDs, much less reels.

But e.g. here: https://forums.freebsd.org/threads/...-bridge-with-ethenet-cards.86482/#post-581869
By setting up the WiFi daemon, when restarting it, suddenly the system sets the network name to "SampleSSID" even though the name was set to "Mynetwork".

Code: 
wlan0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:1e:52:72:e9:0b
        groups: wlan
        ssid SampleSSID channel 13 (2472 MHz 11g ht/40-) bssid 00:1e:52:72:e9:0b
        regdomain JAPAN country JP indoor ecm authmode WPA2/802.11i
        privacy MIXED deftxkey 2 AES-CCM 2:128-bit txpower 15 scanvalid 60
        protmode CTS ampdulimit 64k ampdudensity 8 shortgi -stbc -ldpc -uapsd
        wme burst dtimperiod 1 -dfs
        parent interface: ath0
        media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng <hostap>
        status: running
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
 
Normally, settings stick if you edit .conf files, like application.conf, or /etc/rc.conf or /boot/loader.conf... The Handbook does make a point to remind users to edit those files to make the new changes survive reboots and other situations.

Wifi, however, does remain a sticking point, even for me, even after I do all that. That makes me suspect that in case of wifi, there's something else in the networking stack besides /etc/wpa_supplicant.conf that needs to be ironed out.
 
But it's not just there. This appears in daemons such as IPFW, rtorrent. In Rtorrent, it works this way: if set a daemon and I want to change its settings, it works until system restart. After restarting the computer, it uses the old config and I have to manually reload and then it works on the new one config. I don't know where he got them from. https://forums.freebsd.org/threads/...nt-and-rutorrent-on-lighttpd-full-guide.85230.

I don't know what the conditions are for this to happen and what causes it. It does not depend on the file system, it is the same on ZFW and UFS and nor on the system version. :(
 
I can tell you, /etc/rc.conf sticks and survives reboots.

If your new settings do not stick, make sure you have followed the setup instructions completely and correctly, from the very beginning. From what I've seen on these Forums, messes happen if users just pick out a step they think is most relevant, and do just that step, skipping everything else.

ZFS/UFS and system version are irrelevant if setup instructions are not followed correctly and completely.

Pro-tip: Don't confuse rTorrent with ruTorrent... the latter is a front-end to former. Paying attention makes a difference.

Pro-tip 2: Maybe use a different torrent client, one that is easier to set up? I use KTorrent.
 
In my opinion, it is about creating an executable file based on daemon scripts, and this file, once created, is not overwritten correctly by the new version.
 
LkderS4KGc2bFd63rM said:
In my opinion, it is about creating an executable file based on daemon scripts, and this file, once created, is not overwritten correctly by the new version.
Click to expand...
Instead of wild theories (I don't even get what this should mean, but there are definitely no executables "created" by "scripts", unless you're building software, which has nothing to do with configurations), please just describe in detail (and, ONE case), what exactly you did (all relevant config files and commands executed), what you expected as a result, and what you observed instead.
 
On the example of rtorrent/rutorrent.

I set a configuration in the daemon that worked. I wanted to change a few parameters in the daemon. Instead of adopting the new configuration, the system continued to use the old one after turning the computer off and on. By the way. It works the first time, so is possible to install the system once with the correct settings.
 
LkderS4KGc2bFd63rM said:
In my opinion, it is about creating an executable file based on daemon scripts, and this file, once created, is not overwritten correctly by the new version.
Click to expand...
That's not how FreeBSD (or even Linux) works. 😩 🤷‍♂️

FreeBSD at least has an official source of information that you can refer to when doing your setups: Handbook and manpages.
 
The configuration file in the rc.d folder was changed. The problem only manifests itself when the file is changed. I reduced the number of peers per torrent.
 
Oh wow. /etc/rc.d and /usr/local/etc/rc.d do not contain configuration files but init scripts. You are not supposed to change them. Those in /etc belong to the base system, those in /usr/local/etc to individual ports/packages (and yes, they WILL be overwritten on install/upgrade).

edit: Of course you can place your own init scripts in /usr/local/etc/rc.d if there's ever a need to do so (which should be rare). But don't ever touch scripts installed by ports.

If you expect any help with your issue, please finally give all the details.
 
  • Like
Reactions: mer
LkderS4KGc2bFd63rM said:
It wasn't me who made the mistake.
Click to expand...
Look, I don't even know what this should mean now, but if anyone else has root access to your machine and "making mistakes" there, that's another issue to solve and most likely not a technical one ... so let's ignore that for now.

I'd be happy to help here, as are many other users on here, but for that we finally need some detailed infos what exactly you are doing. 🤷‍♂️
 
  • Like
Reactions: mer
After changing the configuration, I did not remove the temporary files from /var/db.

There are several possible reasons why the daemon continues to use the original configuration file even after it has been changed:

Failure to read new configuration file: If a daemon loads a configuration file during its startup and stores this data in memory or applies it statically, then even if the file is changed later, the daemon will still use the original version until it is restarted or reloads the configuration file .
Errors in the configuration reload process: If a daemon has a mechanism for reloading the configuration at runtime (for example, via the SIGHUP signal), but this mechanism does not work correctly or has not been configured correctly, the daemon may still use the original configuration even after it has been changed.
The configuration file is locked by another process: If the configuration file is being used by another process and is locked in exclusive mode (e.g., when another program is editing the file), the daemon may have trouble reading the changed data until the file is freed.
Errors in the daemon implementation: In some cases, errors in the daemon source code itself can cause the daemon to not respond correctly to changes to the configuration file or to not reload the configuration as it should.
Configuration data cache: Some daemons may use a cache for configuration data, which means that even though the configuration file is changed, these changes are not immediately reflected in the daemon's operation until the cache is cleared or reloaded.

The solution to the problem depends on the specifics of the daemon and its configuration. In some cases, restarting the daemon may be enough; in other cases, you may need to modify the daemon configuration or fix errors in the source code.
Click to expand...

In FreeBSD, daemons and their configuration files can be stored in different locations on disk. Here are some common folders where they can be stored:

/etc/rc.d: This directory contains initialization scripts for various system daemons. These scripts are used to start, stop and manage various services during system startup and shutdown.
/usr/local/etc/rc.d: Often, user-installed software or additional software installed from FreeBSD ports stores its initialization scripts in this directory. Configuration files for these daemons can also be stored here.
/etc: This directory contains various system configuration files, including configuration files for some daemons.
/usr/local/etc: Similar to /etc, this directory may contain configuration files for user-installed software or additional software.
/var/db: Some daemons may store their data, including configuration files, in the /var/db directory or its subdirectories.
/usr/local/etc/<demons_name>: Sometimes daemons store their configuration files in dedicated directories in /usr/local/etc.

Please note that these locations may vary depending on your system configuration and installed software. It's always a good idea to check the documentation for your software or initialization scripts to find out where the configuration files for specific daemons are stored.
Click to expand...

Powered by GPT.
 
LkderS4KGc2bFd63rM said:
if set a daemon and I want to change its settings, it works until system restart. After restarting the computer, it uses the old config and I have to manually reload and then it works on the new one config.
Click to expand...
When rebooting the system executes the old rc(8) scripts (daemons) and manually the modified, where are those custom scripts in question located ? Please give us the exact location (full path).

How exactly do you manually execute the modified scripts (exact command)?

Are there maybe multiple rc(8) scripts with the same name? One under /etc/rc.d the other under /usr/local/etc/rc.d.
 
Where are these custom scripts in question located?
Click to expand...
in the rc.d daemon folders

How exactly do you manually execute the modified scripts (exact command)?
Click to expand...
I doesn't do it itself. I use "reboot" or "service command" #service service_name restart.

Are there maybe multiple rc(8) scripts with the same name? One under /etc/rc.d the other under /usr/local/etc/rc.d.
Click to expand...
There are no other scripts in the rc.d folders.

But this doesn't explain why, for example, WiFi took the name "SampleSSID" out of a hat. Or why ipfw ignored the configuration file and took one of the default configurations.
 
LkderS4KGc2bFd63rM said:
Through a text file editing program, ee.
Click to expand...
You misunderstood me. I asked how did you execute the rc(8) script, not how did you edit it. For example:
Code: 
service rtorrent restart
/usr/local/etc/rc.d/rtorrent restart

LkderS4KGc2bFd63rM said:
But this doesn't explain why, for example, WiFi took the name "SampleSSID"
Click to expand...
Run as root grep -r SampleSSID /etc /usr/local/etc.

This should show which file does the configuration.

LkderS4KGc2bFd63rM said:
Or why ipfw ignored the configuration file and took one of the default configurations.
Click to expand...
Have you set the ipfw configuration file to be executed in /etc/rc.conf by absolut path and by name?

If the ipfw configuration file is not set explicitly by path and name in /etc/rc.conf, the configuration will default to /etc/defaults/rc.conf firewall_script="/etc/rc.firewall" # Which script to run to set up the firewall .

A custom ipfw configuration file would be for example firewall_script="/etc/ipfw.rules"
 
Use .conf files to make changes stick, buddy. Don't confuse them with service daemons in rc.d/ or with flags that you pass to the binary on startup. They are totally separate things.

If you're still confused, please refer to the Handbook for initial setup instructions.

Yeah, wifi is a sore spot, but let's focus on trying to understand the difference between making config changes and loading config changes.
 
and please stop reproducing this wrong and confusing naming.

A "daemon" is a Unix process that detaches itself from the controlling terminal (doing several typical steps like starting its own session, closing all stdio streams, changing the working dir to /, forking itself, etc ... so that it runs fully independently from the environment that started it) and then normally offers some service. On BSD systems, there's the helper function daemon(3) available to do most of this easily.

What's found in /etc/rc.d is something completely different: Shell scripts used to start/stop and otherwise control services, called init-scripts. They will typically start daemons, but could also start other applications offering services (using some workarounds to "detach" them) -- or even do something completely different like e.g. setting up networking and routing.
 
You must log in or register to reply here.
Back
Top