How to tell FreeBSD to stop producing pkgsave files.

How did you install the tor at the first time? Did you follow some random internet guide and create/extract by hand /usr/local/etc/rc.d/tor?
Share the link to it.
 
Has nothing to do with the existence of those .pkgsave copies.

I think it has to do with the .pkgsave files,because I have removed it and I haven't seen duplicated executables anymore. And even no more than 1 port opened. Or better : the same port opened more times.
 
Just run find /usr/local -type f -name '*.pkgsave' -delete and be done. And I hope you didn't install things manually that ended up in /etc and/or {,/usr}/{,s}bin.
 
Just run find /usr/local -type f -name '*.pkgsave' -delete and be done. And I hope you didn't install things manually that ended up in /etc and/or {,/usr}/{,s}bin.

I suspect that your command is not able to distinguish between a .pkgsave that's an executable and a .pkgsave that's a configuration file. Is this right ? I find useful to have a backup of the old configuration files. The script should detect if the .pkgsave file is +x before to remove it.
 
Configuration files are not overwritten, they get stored as *.sample if one already exists. If it didn't do this it would overwrite the config file with a default config on every update of that port/package. Updates are basically a pkg-delete(8) followed by a pkg-install(8). That never overwrites existing configuration files, they are left in place (and aren't renamed to *.pkgsave either).
 
We can get these files as an example :

Code:
/usr/local/lib/libgnutls.so.30.34.2.pkgsave
/usr/local/lib/libIntelXvMC.so.1.0.0.pkgsave
/usr/local/lib/libruby30.so.30.pkgsave
/usr/local/lib/libgconf-2.so.4.1.5.pkgsave
/usr/local/lib/libICE.so.6.3.0.pkgsave
/usr/local/lib/libabsl_flags_commandlineflag.so.2111.0.0.pkgsave
/usr/local/lib/libabsl_random_internal_randen.so.2111.0.0.pkgsave
/usr/local/lib/libabsl_cord_internal.so.2111.0.0.pkgsave
/usr/local/lib/libxcb-present.a.pkgsave
/usr/local/lib/libxkbcommon-x11.so.0.0.0.pkgsave
/usr/local/lib/libsoxr-lsr.so.0.1.9.pkgsave
/usr/local/lib/libodbc.a.pkgsave
/usr/local/lib/libxcb.so.1.1.0.pkgsave
/usr/local/lib/libraptor2.la.pkgsave
/usr/local/lib/libfm.so.4.1.3.pkgsave
/usr/local/lib/libpangoft2-1.0.so.0.5000.9.pkgsave

Will your script delete everything ? But why should I do that ? the pkgsave files you see aren't executables. They don't mess up the system. How many kind of files are backupped on the system that aren't executables ?
 
your script will delete everything. But why should I do that ?
You wanted to clean up your system, or not? If you want to clean up, remove everything that ends with *.pkgsave.

the pkgsave files you see aren't executables.
No, those are libraries. Probably installed by whatever you built from source yourself. Get rid of them, they've been replaced by proper port/package versions anyway (that's why those *.pkgsave files exist in the first place). They will never be referenced or loaded as their naming convention doesn't match what is expected of libraries.

find /usr/local -type f -name '*.pkgsave' | xargs rm -i
Now it's going to ask if you want to remove each file individually.
 
I’m starting to wonder if you had somehow deleted pkg’s database (/var/db/pkg/local.sqlite) of what was installed, and that’s why you’re having all of these issues — when you went to install things again, there were a number of files “unexpected” (not recorded in pkg’s DB) which led to all the .pkgsave files. Either that, or you installed software in /usr/local without pkg’s knowledge.

Your issues are not experienced by the other users on this forum, so there appears to be something different in how you got to your state, compared to how most people are configured. I would be tempted to make a copy / tarball of /usr/local, ask pkg to remove everything, then manually remove everything under /usr/local, and start fresh with pkg-static install …
 
Just run find /usr/local -type f -name '*.pkgsave' -delete and be done. And I hope you didn't install things manually that ended up in /etc and/or {,/usr}/{,s}bin.

I suspect that your command is not able to distinguish between a .pkgsave that's an executable and a .pkgsave that's a configuration file. Is this right ? I find useful to have a backup of the old configuration files. The script should detect if the .pkgsave file is +x before to remove it.

Ok, then try this, as root:

find /usr/local -type f -name '*.pkgsave' -exec chmod a-x {} \;

Or even "find / ..." to be sure.

That leaves them all in place - whether or not a good idea - but disables execution of especially service scripts in {/usr/local,}/etc/rc.d

You should see a warning logged on attempting to start any disabled script, but you won't get extras running.

Time spent getting to know find(1) will be rewarded many times over.
 
No, that has nothing to do with it. It's the /usr/local/etc/rc.d/tor.pkgsave that caused it to get started twice. And that script will simply execute /usr/local/bin/tor, not /usr/local/bin/tor.pkgsave. The rc(8) file itself has been renamed, its contents aren't modified.
How's it possible that a script like /usr/local/etc/rc.d/tor.pkgsave started automatically?
It's hard to believe it's enabled in /etc/rc.conf, thus the corresponding daemon/service must be started with onestart switch.
 
How's it possible that a script like /usr/local/etc/rc.d/tor.pkgsave started automatically?
Because all scripts in /usr/local/etc/rc.d/ are executed during boot?

It's hard to believe it's enabled in /etc/rc.conf, thus the corresponding daemon/service must be started with onestart switch.
Simple, it had tor_enabled="YES" in rc.conf intended to start /usr/local/etc/rc.d/tor, but /usr/local/etc/rc.d/tor.pkgsave uses that same variable, thus it also gets started. The variable that defines if the service is enabled or not isn't depending on the name of the rc.d(8) script, it's set by the rcvar variable that's defined within that script. The contents of the tor.pkgsave rc(8) script hasn't changed, only the name of the script itself has.
 
Because all scripts in /usr/local/etc/rc.d/ are executed during boot?

Indeed, and thanks for the reminder, which explains a spurious message here on startup and shutdown from not-enabled powerdxx

However, according to rc(8) they are each executed by run_rc_script from rc.subr(8), which specifically ignores non-executable files, right?
 
Yes, there's some logic that detects the old style *.sh scripts and to filter backup and RCS files.

Code:
  case "$_file" in
  /etc/rc.d/*.sh)     # no longer allowed in the base
    warn "Ignoring old-style startup script $_file"
    ;;
  *[~#]|*.OLD|*.bak|*.orig|*,v) # scratch file; skip
    warn "Ignoring scratch file $_file"
    ;;
  *)        # run in subshell
    if [ -x $_file ]; then
      if [ -n "$rc_fast_and_loose" ]; then
        set $_arg; . $_file
      else
        ( trap "echo Script $_file interrupted >&2 ; kill -QUIT $$" 3
          trap "echo Script $_file interrupted >&2 ; exit 1" 2
          trap "echo Script $_file running >&2" 29
          set $_arg; . $_file )
      fi
    fi

You could file a PR and try to get *.pkgsave added to that list of files to ignore. The OP's issue is probably a good reason to add that.
 
Because all scripts in /usr/local/etc/rc.d/ are executed during boot?


Simple, it had tor_enabled="YES" in rc.conf intended to start /usr/local/etc/rc.d/tor, but /usr/local/etc/rc.d/tor.pkgsave uses that same variable, thus it also gets started. The variable that defines if the service is enabled or not isn't depending on the name of the rc.d(8) script, it's set by the rcvar variable that's defined within that script. The contents of the tor.pkgsave rc(8) script hasn't changed, only the name of the script itself has.

I think that you got the point. So,now,what do you think about the specific behavior that you have explained ? Can it be improved or not ? If it produces a lot of .pkgsave executables,it will mess up the system. I think that the fix could be to set -x to the executables .pgksave files. You suggested some scripts to do what I want,but they do a task that it's not exactly what I want or,the latest one,it is for me,not so much understandable and/or uselessly complicated. The script that I would like to have should accomplish two or 3 easy tasks :

1) ask into which directory it should look for the .pkgsave files
2) detect if the .pkgsave file is +x (making a loop for detecting every .pkgsave file in the directory selected on point 1)
3) if it is +x,make -x

done. My ultimate goal is to preserve the system files as much as possible as they are.
 
I think that the fix could be to set -x to the executables .pgksave files.
No, it shouldn't touch the permissions of the file. A better solution is to get /etc/rc.subr changed and add *.pkgsave to the list of files to ignore from /etc/rc.d and /usr/local/etc/rc.d. You should create a PR for this, you have a good use-case for the change.

It's only the rc(8) scripts that could potentially cause problems, random executables and/or libraries that have the *.pkgsave postfix are irrelevant, they're never going to be executed or loaded.
 
No, it shouldn't touch the permissions of the file. A better solution is to get /etc/rc.subr changed and add *.pkgsave to the list of files to ignore from /etc/rc.d and /usr/local/etc/rc.d.

what's the problem with my approach ? I don't understand this. And anyway,I don't understand when I should run your script. Before to see that the .pkgsave / executable files have been ran or after that ? should I place your script somewhere ? into which directory ? Can you explain how it works ? otherwise I cannot use it,because if I use it in the wrong way,it could produce damages hard to fix. The reason why I tend to ask for custom scripts is because I know what I understand and what not and I want to keep things easy,to my level of understanding or,at least,only a little more complicated.
 
what's the problem with my approach ? I don't understand this.
Your own argument:
My ultimate goal is to preserve the system files as much as possible as they are.
Changing the permissions of those files wouldn't preserve them.

And anyway,I don't understand when I should run your script. Before to see that the .pkgsave / executable files have been ran or after that ?
On a properly maintained system those files shouldn't get created in the first place. I've never had a single one in all the years I've been using pkg(8) (I originally started using it on 9.x when the old pkg_* tools were still the default).
should I place your script somewhere ? into which directory ?
For now you can just run it to clean up the mess. No need to save it anywere, unless you want to keep it. /root/bin is a nice place for ad-hoc scripts like this.

Can you explain how it works ?
find(1) is super powerful and useful, you'd do well to learn how to use it. It'll come in handy in many situations. I'll try to break down the command for you:
find /usr/local -type f -name '*.pkgsave' -delete
This will start in /usr/local/ and enumerate everything below it, down through all subdirectories below it. -type f tells it to only look for files, -name '*.pkgsave' then further constrains the search to only look for files matching the file glob, in other words, every file that ends with .pkgsave. This results in a list of files and -delete tells find(1) to delete everything on that list.

Code:
     -type t
             True if the file is of the specified type.  Possible file types
             are as follows:

             b       block special
             c       character special
             d       directory
             f       regular file
             l       symbolic link
             p       FIFO
             s       socket
Code:
     -name pattern
             True if the last component of the pathname being examined matches
             pattern.  Special shell pattern matching characters (“[”, “]”,
             “*”, and “?”) may be used as part of pattern.  These characters
             may be matched explicitly by escaping them with a backslash
             (“\”).
Code:
     -delete
             Delete found files and/or directories.  Always returns true.
             This executes from the current working directory as find recurses
             down the tree.  It will not attempt to delete a filename with a
             “/” character in its pathname relative to “.” for security
             reasons.  Depth-first traversal processing is implied by this
             option.  The -delete primary will fail to delete a directory if
             it is not empty.  Following symlinks is incompatible with this
             option.
 
No man. You have more experienced than me. What for you is an easy solution,for me it's too much complicated. If I don't understand what the script will do deeply,I will not run it. From my point of view,my 3 steps are easier to understand and manipulate. Anyway,can you reload the page ? I could try to run your script,but before to do that,please can you reply to my questions ? (asked on comment #41). thanks.
 
You have more experienced than me. What for you is an easy solution,for me it's too much complicated.
There once was a time when I didn't know how to use find(1) either. Read my signature.

I could try to run your script,but before to do that,please can you reply to my questions ?
Run the command without the -delete at the end, that will simply produce a list of files and you can verify it doesn't contain anything you wanted to keep. Then if you're satisfied that list is good add the -delete at the end. I always do the same, keep fiddling with the search parameters until I'm satisfied it only matches with the things I want. Then I'll add the -delete to have them deleted.
 
Ohhh. You are talking about this script :

Code:
find /usr/local -type f -name '*.pkgsave' -delete

and not about this :

Code:
case "$_file" in
  /etc/rc.d/*.sh)     # no longer allowed in the base
    warn "Ignoring old-style startup script $_file"
    ;;
  *[~#]|*.OLD|*.bak|*.orig|*,v) # scratch file; skip
    warn "Ignoring scratch file $_file"
    ;;
  *)        # run in subshell
    if [ -x $_file ]; then
      if [ -n "$rc_fast_and_loose" ]; then
        set $_arg; . $_file
      else
        ( trap "echo Script $_file interrupted >&2 ; kill -QUIT $$" 3
          trap "echo Script $_file interrupted >&2 ; exit 1" 2
          trap "echo Script $_file running >&2" 29
          set $_arg; . $_file )
      fi
    fi

I can understand and manipulate the first one,but not the second. I'd thought you were talking about the 2.
 
And anyway. I understand this easy command line :

Code:
find /usr/local -type f -name '*.pkgsave' -delete

anyway I find it partially useful. It makes a list with all the .pkgsave files located on the /usr/local directory. It will include every kind of files,executable or not. I need that it detects and generates a list with only the executables ones. Because they are the only files which cause troubles to the system. Can you add a filter ? Before you created a similar script that asks if I want to remove each file individually : the problem is that I can't give a good answer if I don't know if the file is executable or not. I find comfortable if the script can filter from the beginning which pkgsave file is exe or not. thanks.
 
I can understand and manipulate the first one,but not the second. I'd thought you were talking about the 2.
That was a couple of lines from /etc/rc.subr where the issue could easily be fixed. It already filters a couple of other file postfixes (like .bak and .orig). Adding *.pkgsave would prevent the system from ever executing a *.pkgsave file in /etc/rc.d/ and /usr/local/etc/rc.d/ (and any directory referenced in local_startup).
 
That was a couple of lines from /etc/rc.subr where the issue could easily be fixed. It already filters a couple of other file postfixes (like .bak and .orig). Adding *.pkgsave would prevent the system from ever executing a *.pkgsave file in /etc/rc.d/ and /usr/local/etc/rc.d/.

I've explored my /etc/rc.subr file. The portion of code that you showed is the same code that I have inside that file. You haven't fixed anything,right ?
 
Back
Top