Add rcvar to rc.d/utx
I wonder why so many services lack rcvars? Is it by design?
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 30488 Build 28240: arc lint + arc unit
Event Timeline
Comment Actions
I suspect mostly it is laziness, although in this case I think it is by design. Tentative NACK. Why do you want to disable it?
Comment Actions
Disabling utx boot and utx shutdown does not prevent other parts of the system writing to the utx files. So by itself this disable creates utx files that are less useful. Disabling utx completely needs patching, at least the way things are now.
Given that every configuration option makes it harder to configure the system, I'm not sure this is worth it.
Comment Actions
Well, there are a couple of reasons. Some are more practical, some are more philosophical:
- It's been confusing to me (and also some other FreeBSD users in various threads around the web I've come across) that not every service could be disabled. utx is just one of them, and is a relatively simple one to fix.
- I am working with non-server FreeBSD systems, which used to ship with custom rc scripts. There is a desire to bring those much closer to the stock FreeBSD and one of the steps is switching to the standard rc scripts we've got in base. Now, some of the stock FreeBSD services (e.g., utx) make no sense on those machines. So instead of creating workarounds (e.g., removing the service file or adding rcvar=utx_enable; utx_enable=NO to /etc/rc.conf.d/utx) I decided to submit a patch.
- In a way, utx could be disabled by recompiling the base with WITHOUT_UTMPX set. I would prefer to stick to the release versions of FreeBSD, however. (Also, in general not every rc script lacking rcvar in the base system could be disabled this way.)
Comment Actions
The trouble is that disabling utx is actually more complicated than this (and removing the service file is not an effective quick hack either). Jilles gave some detail above. I’m not sure it’s an especially useful thing to spend time on wrt improving desktop FreeBSD experience; it just goes to a daily log file end users can ignore.
Edit: I’ll add: utx is less of a “service” and more in the original spirit of rc: it’s just a program that runs once at boot and once at shutdown. Enabled or disabled, there is no utx process at runtime.
Comment Actions
I'll agree with Conrad and Jilles in that it's adding a configuration value (needlessly?) and doesn't really do what it's advertised to do anyway.
Utx files are modified by a function call in libc, and to disable it properly you'd need to recompile the whole system, or at least hack it out of libc!
Comment Actions
Oh, I think that I wasn't precise enough in my explanation of what I am trying to achieve. Sorry about that.
My use case is as follows:
- to use stock FreeBSD without building my own base
- to avoid having to modify service files from base to disable them
- to avoid hacks like putting rcvar=utx_enable; utx_enable=NO into /etc/rc.conf.d/utx in order to disable the utx service
Now, I am aware that merely disabling the utx service is not disabling every utx-related bit on the system.
So, the more I think about the whole patch, the more I'm convinced that from the FreeBSD perspective it makes little sense: if someone wants to disable utx, then they should rebuild the base. As you said, just disabling the service is most likely not what the user wants.
In summary then, I this patch should probably be abandoned.
On the other hand, I believe that rcvar should be defined in every script for consistency, however, I should probably move the discussion about it to the rc@ mailing list.
Comment Actions
I think re (2), this is not really a service file. It’s a run command. Like cleanvar or FILESYSTEMS.
If you want to be able to disable the utx mechanism at runtime, and do so using an rcvar, I think that is achievable and broadly reasonable. It just requires changes to libc that this patch doesn’t include.