CPU overheating risk still present in latest 7.2?

[Entropic]

Hi All,

I'm now running this OpenBSD system in the Australian summer, and I seem to remember back when I was looking at various guides for OpenBSD newbies back in November 2022 that you needed to alter some kind of system config file to ensure the CPU wasn't constantly running at 100% (to prevent it cooking).

I think someone like Solene had a clever solution for it..

Anyways, is it even something I need to worry about, or was it only applicable to older versions of OpenBSD? I'm running the latest 7.2.

[nipos]

There's a tool called obsdfreqd that takes care of your CPU frequency: https://tildegit.org/solene/obsdfreqd
You simply need to install it from the official repo and enable the daemon.
In most cases,the default settings are fine and you don't need to change anything.

[fvgit]

An alternative method to obsdfreqd (if you compile the kernel from source) was outlined by OpenBSD developer Stuart Henderson:

Other than obsdfreqd there's a 1-line change in sys/kern/sched_bsd.c some of us use instead, I think it's better done in the kernel than by running by an extra program - change "if (hw_power) {" to "if (0 && hw_power) {".

Though, if you're a newbie you're probably better served following nipos' suggestion and using obsdfreqd from the ports collection.

[Entropic]

Originally Posted by nipos

There's a tool called obsdfreqd that takes care of your CPU frequency: https://tildegit.org/solene/obsdfreqd
You simply need to install it from the official repo and enable the daemon.
In most cases,the default settings are fine and you don't need to change anything.

Thanks so much for the link. I've just pkg_add (ed) it following the TLDR instructions on Solene's page, but I'm a little confused as to how it will run when I'm logging into my OpenBSD in the default non root form (It says that it needs to be run in root). I don't want to have to retype all those rcctl commands, and would rather have apmd (power mgmt) running concurrently with it, so how would I go about arranging that. Is there some kind of .conf file I need to make or edit with Vi ?

[jggimi]

You shouldn't have to retype rcctl commands. The "rcctl enable" command you entered will cause the daemon to be started at boot time. See the rcctl(8) man page for more detail on how the tool works, and a little more about how your commands end up provisioning instructions in /etc/rc.conf.local. You may find the rc.conf.local(5) man page helpful, too.

[Entropic]

Originally Posted by jggimi

You shouldn't have to retype rcctl commands. The "rcctl enable" command you entered will cause the daemon to be started at boot time. See the rcctl(8) man page for more detail on how the tool works, and a little more about how your commands end up provisioning instructions in /etc/rc.conf.local. You may find the rc.conf.local(5) man page helpful, too.

Thanks Jggimi. To clarify: by successfully entering rcctl commands once, they will persist for subsequent reboots of the system? Or do you mean that entering an rcctl command in the one boot session means it persists?

On that point, currently to shut down my OpenBSD laptop I type "exit" at the prompt before pressing the power button. Is there a command line entry for actually turning the laptop off?

[Onauk]

Hi Entropic, the "rcctl enable" command persists for subsequent reboots of the system.

To shutdown the laptop you can type

shutdown -p now

as is described in shutdown(8).

[jggimi]

Originally Posted by Entropic

To clarify: by successfully entering rcctl commands once, they will persist for subsequent reboots of the system? Or do you mean that entering an rcctl command in the one boot session means it persists?

Briefly:

• These rcctl commands change the contents of /etc/rc.conf.local: disable, enable, order, set.
• These rcctl commands act on and change the operation of daemons immediately: reload, restart, start, stop.

[Entropic]

Originally Posted by Onauk

Hi Entropic, the "rcctl enable" command persists for subsequent reboots of the system.

To shutdown the laptop you can type

shutdown -p now

as is described in shutdown(8).

Thank you kindly Onauk for making this so clear.

[Entropic]

Originally Posted by jggimi

Briefly:

• These rcctl commands change the contents of /etc/rc.conf.local: disable, enable, order, set.
• These rcctl commands act on and change the operation of daemons immediately: reload, restart, start, stop.

Thanks Jggimi, and therefore in applying this rule to the obsfreqd installation instructions:

    pkg_add obsdfreqd
    as root rcctl enable obsdfreqd and rcctl stop apmd ; rcctl disable apmd
    as root rcctl start obsdfreqd
    apmd can be kept but not with flag -A
    if any tuning is needed, it may be -T for temperature limit

Is it therefore the case that the "rcctl start obsdfreqd" line won't persist into the next reboot even if rcctl enable does, and therefore I'll need to "start" it again at each boot?

[jggimi]

Additional clarity is needed, as there is confusion between settings in rc.conf.local(5) and immediate actions that start and stop daemons. Let's go through these command-by-command:

• # rcctl enable obsdfreqd: adds an empty obsdfreqd_flags= to rc.conf.local and adds 'obsdfreqd' to the pkg_scripts variable. This daemon will be started by rc(8) at the next boot with its defaults, as the obsdfreqd_flags variable is empty.
• # rcctl stop apmd: halts the apmd(8) daemon if it is running.
• # rcctl disable apmd: removes any apmd_flags setting from rc.conf.local. This prevents apmd(8) from starting at the next boot, as the default apmd_flags setting located in -- note the different but similar file name -- /etc/rc.conf is apmd_flags=NO.
• # rcctl start obsdfreqd: this starts the obsdfreqd(1) daemon with its default settings.

As an example, I have these key fragments in my laptop's /etc/rc.conf.local file:

apmd_flags=-H -Z 10
[snip]
obsdfreqd_flags=-T 85
pkg_scripts=unwind1 smartd obsdfreqd messagebus avahi_daemon cupsd
[snip]

My system starts both apmd(8) and obsdfreqd(1) during a normal boot. Note that for my use-case, both my apmd_flags and obsdfreqd_flags variables are not blank, they have non-default settings applied. The pkg_scripts variable is the order for starting third party package daemons. The apmd daemon is not listed, because that is a built-in daemon, controlled first by default settings in /etc/rc.conf, then overridden by settings in /etc/rc.conf.local.

I hope this explanation was helpful and did not confuse you further.

[Entropic]

Originally Posted by jggimi

Additional clarity is needed, as there is confusion between settings in rc.conf.local(5) and immediate actions that start and stop daemons. Let's go through these command-by-command:

• # rcctl enable obsdfreqd: adds an empty obsdfreqd_flags= to rc.conf.local and adds 'obsdfreqd' to the pkg_scripts variable. This daemon will be started by rc(8) at the next boot with its defaults, as the obsdfreqd_flags variable is empty.
• # rcctl stop apmd: halts the apmd(8) daemon if it is running.
• # rcctl disable apmd: removes any apmd_flags setting from rc.conf.local. This prevents apmd(8) from starting at the next boot, as the default apmd_flags setting located in -- note the different but similar file name -- /etc/rc.conf is apmd_flags=NO.
• # rcctl start obsdfreqd: this starts the obsdfreqd(1) daemon with its default settings.

As an example, I have these key fragments in my laptop's /etc/rc.conf.local file:

apmd_flags=-H -Z 10
[snip]
obsdfreqd_flags=-T 85
pkg_scripts=unwind1 smartd obsdfreqd messagebus avahi_daemon cupsd
[snip]

My system starts both apmd(8) and obsdfreqd(1) during a normal boot. Note that for my use-case, both my apmd_flags and obsdfreqd_flags variables are not blank, they have non-default settings applied. The pkg_scripts variable is the order for starting third party package daemons. The apmd daemon is not listed, because that is a built-in daemon, controlled first by default settings in /etc/rc.conf, then overridden by settings in /etc/rc.conf.local.

I hope this explanation was helpful and did not confuse you further.

It certainly gives a lot of extraneous information other than what I was looking for. Nowhere does it answer my simple question as to whether rcctl start obsdfreqd persists at next boot when entered in the command line on a previous boot.

If you'd like to answer the question rather than playing gatekeeper and trying to impress everyone with your general knowledge please feel free to reply...

[jggimi]

I was trying to help.

We're done. I won't try again.

I wish you well.

[J65nko]

The rcctl command you used changed/added a persisting setting in a system configuration file for you.

Before this command appeared in OpenBSD you had to manually edit this configuration file with an editor. Sometimes people made a syntax error in this file and thus causing problems. That is why this command was added.

This configuration file is consulted during start of the system. So the obsdfrefq daemon will be started each time you boot the system.

So rcctl will not be run at boot up, it is an interactive utility to make less error-prone changes to the system startup configuration file.

[Entropic]

J65nko,

Thanks for clarifying this directly and with the history context. What do you think about re-enabling apmd to combine the benefits of obsdfreq with apmd for a comprehensive power and heat management solution. I understand from Solene's that I need to avoid a certain flag (argument) in the command line for apmd to do this...

[J65nko]

I have no experience with both apmd and obsdfreq.
What does Solene say about this special flag to avoid?

[albator]

J65nko, instead of a technical answer, I think a warning would have been more appropriate.
I say this, assuming you administrate this forum (sorry if Im wrong).

For starters, the claim that the CPU is in danger is false and secondly the answer was already given by jggimi.
As usual, not only he answers but also takes time to explain how things work, presuming the questioner is eager to learn.

This is not the case with the original poster who seems better at being rude than at searching solutions for simple problems.
This attitude does not go well with the use of OpenBSD that requires a lot of self teaching by reading documentation.

[Head_on_a_Stick]

Originally Posted by albator

the original poster who seems better at being rude than at searching solutions for simple problems

The OP is engaging in behaviour known as sealioning. It's probably best to just ignore them.

[Entropic]

Anyone who looks at the questions I've asked since joining these forums in November last year will realise that I have nothing but a genuine interest in learning what is recognised universally as a difficult to learn and non user friendly operating system. In the absence of being able to provide typescripts or screenshots I've done my damned best to provide all necessary info for troubleshooting in well worded and explained replies.

Many of the responses I've received have been helpful, but similarly many have been unhelpful where the replying person often has other motivating factors that override their intention to offer genuine help. Take for example jggimi who has demonstrated a tendency to answer any queries with more emphasis on showing his wide ranging knowledge rather than directly answering the question. Of course each time its been dressed up as purely rational advice giving. This is a person who revels in controlling threads by monopolising replies and even discouraging potentially helpful replies from others who may actually have something useful to offer, such as how to get OpenVPN working - an area he would simultaneously acknowledge knowing little about, but then also adjudicate that nobody else in these forums would basically know if he didn't know - thus discouraging any potentially helpful replies. See here in case you're unfamiliar with the thread: https://daemonforums.org/showthread....3489#post73489

PS: It seems that most VPN providers use OpenSSL, and not embedTLS, which was one of the two installation prompts given when installing the OpenVPN daemon.

Then we have the blatent trolls such as Head_On_A_Stick (Matthew) who as I've recently shown in my other recent thread (https://daemonforums.org/showthread.php?t=12350&page=2 and the original: https://daemonforums.org/showpost.ph...6&postcount=37) offer help but then resent any further clarification queries on their given answer. I have little doubt you've put good effort into making your reply, but don't be frustrated if some questions remain. You didn't learn this overnight, and you shouldn't expect others to either.

In this latest reply you have resorted to stereotyping me in saying I'm "Sealioning" after just a few days earlier accusing me of being a "Help Vampire". So which is it? Have you made up your mind up or will we see a third, fourth and so on steretyping smear attempt? So aggrieved are you by my showing you up as the bitchy nerd elitist that you are, you would now try and use my strengths (maintaining civility in spite of overt bullying) to selectively build a straw man (sealion) for further castigation by yourself and others.

Note that in the last couple days after I've shown a willingness to maintain a good working relationship on this forum in spite of his intolerant elitism, Recently he has changed his avatar signoff to "Bitchy Nerd Elitist" as an attempt to devalue this accurate description made of him. I've tried to make light of this and keep things positive by changing my own sign off to "Help Vampire - Super user" to remind him that we all need the ability to see our own faults, and not take it too seriously when others point these out as a means to improve future relations and tech troubleshooting (See here: https://daemonforums.org/showthread.php?t=12350&page=2 )

Then, having seen as we continued the thread that he had thus failed in his attempt to get under my skin with his avatar headline he's once again shown his true colours by attempting to stereotype me in such a way that vindicates abuse of me by others.

Then we have J65nko, the admin of this board who a couple days ago, unable to find any appropriate justification to silence me, engaged in his own form of bullying by sending me a private message asking that I not quote other people's contextual replies when replying. He argued that it was to save server space.... I asked him how many bytes this might save but he hasn't replied. Perhaps he's trying to save more space??

What a sad indictment of what is generally recognised as one of the only online forums that OpenBSD users in need of genuine help can go to for "help"...
So what now? Will this post, having exposed a few embarrassing realities of this forum be allowed to stand to serve as warning for others seeking genuine help? Or will (as I expect) it be taken down so that the status quo of passive aggressive, and nerdy bullying elitism be maintained into the future?

[Onauk]

Originally Posted by Entropic

So what now? Will this post, having exposed a few embarrassing realities of this forum be allowed to stand to serve as warning for others seeking genuine help? Or will (as I expect) it be taken down so that the status quo of passive aggressive, and nerdy bullying elitism be maintained into the future?

These realities really are embarrassing, I hope J65nko, jggimi and Head_on_a_Stick can sleep well at night and are not eaten up by remorse.