# How to tell FreeBSD to stop producing pkgsave files.



## ziomario (Jan 5, 2023)

Hello.

From the boot messages I see that tor starts two times. So,I'm investigating the reason and I've found that it could be because the system creates a lot of pkgsave files,even with the executables,as you can see below.


```
# find /usr -name "tor*.pkgsave" -print

/usr/local/bin/tor.pkgsave
/usr/local/etc/rc.d/tor.pkgsave

# find /usr -name "tor" -print

/usr/local/bin/tor
/usr/local/etc/tor
/usr/local/etc/rc.d/tor
```

is there a method to tell the system to don't produce them ? otherwise I have a lot of duplicated services that tries to start and a lot of errors happens.


----------



## xedos832 (Jan 5, 2023)

freebsd / pkg issues: pkgsave I found this, I hope it will be useful__


----------



## ziomario (Jan 5, 2023)

Thanks,but not very useful...


----------



## Styrsven (Jan 5, 2023)

Maybe this have some useful info: https://github.com/freebsd/pkg/issues/1924


----------



## ziomario (Jan 6, 2023)

Thanks. Not useful for me. I have a lot of troubles to understand what's the pourpose of pkgsaves. The thread is too much technical for me. The fastest method for me could be to disable them,but on the thread I didn't find how to do it.


----------



## Styrsven (Jan 6, 2023)

I have have no previous knowledge either, but this:


> .pkgsave file only exists when a file wasn't part of a package and now is.
> The old files are kept as pkg doesn't want to be the one to rm them.


Indicates that if preexisting files not installed by pkg is overwritten by pkg, then pkg saves the previous file as a pkgsave file.
Could it be that you installed tor manually and then installed it again from ports/packages?


----------



## gotnull (Jan 6, 2023)

I am far from a technical guy but as I used Linux system before I already encountered rpm.save and pac.save which I guess work the way as pkgsave files do.
Simple explanation (the only way I can do it anyway  ):
Let's say you have already configured your sshd_config and changed the default port 22 to 5226.
Then a SSH update comes, a new sshd_config file is put in place and your old file is now called sshd_config.kpgsave. 
The new config file has port 22 but the pkgsave file has port 5226.
In order to keep everything in line you have to make a diff between sshd_config and sshd_config.pkgsave to bring your own modification into the new config file.

Well sorry I can't explain it better ...


----------



## ziomario (Jan 7, 2023)

Thanks. Now I understand better. What I still does not understand is why a pkgsave file is executable. I think this is the real problem. Infact,when I have deleted the "*/usr/local/bin/tor.pkgsave*" and the "*/usr/local/etc/rc.d/tor.pkgsave*" files and I've rebooted,I started to see what I wanted,one only tor process hearing on one only port. So,I think that the tecnique explained is useful for the configuration files,but not for the executables. At this point,until I don't understand why I should have more executable files hearing on different ports,I'll keep thinking that I need to write a script to detect and remove every pkgsave / executable file that is created.


----------



## gotnull (Jan 7, 2023)

ziomario said:


> What I still does not understand is why a pkgsave file is executable


Could it be because of what Styrsven quoted before in message #6 which would make totally sense .


----------



## ziomario (Sunday at 1:48 PM)

It makes no sense for me. I don't see the utility of having duplicated executable files,rather it creates troubles to me. So,I would like to disable the pkgsave feature for the executable files. Instead,I see that this feature is ok for the config. files.


----------



## gotnull (Sunday at 3:59 PM)

Still you didn't answer the question which would probably help people in the same case ... did you installed it manually  yes or no ?


ziomario said:


> It makes no sense for me. I don't see the utility of having duplicated executable files,rather it creates troubles to me.


It doesn't make sense to you in this situation may be, but it did may be at the time when the developers coded it like this, I guess there is a reason.


ziomario said:


> So,I would like to disable the pkgsave feature for the executable files. Instead,I see that this feature is ok for the config. files.


It's a strange behavior I get that but it's not that difficult to solve either, write a simple script that find all the executable files with an extension ".pkgsave" and delete them if it's more convenient for you.
It looks like not an easy task to find documentation on "pkgsave" so unless someone gives you a better alternative I am afraid that's your best option.

EDIT:
grammar ... sorry


----------



## Alain De Vos (Sunday at 9:50 PM)

A google result,








						pkgsave files and trust stores like /usr/local/etc/pkg/fingerprints · Issue #1924 · freebsd/pkg
					

Hello, What is the intended way to deal with leftover pkgsave files when they should not exist i.e. trust directories like pkg fingerprints? The sticky nature of this feature renders removing or re...




					github.com


----------



## richardtoohey2 (Sunday at 10:44 PM)

ziomario said:


> At this point,until I don't understand why I should have more executable files hearing on different ports,I'll keep thinking that I need to write a script to detect and remove every pkgsave / executable file that is created.


From the links people have sent:

1) The files are created when pkg doesn't know what to do with older files that it doesn't think are needed any more.
2) It can't guess what you want to do with them, so renames them for you to deal with. 
3) It doesn't care what sort of file they are - config, executable, whatever.
4) So yes, it looks like you will need to use a find command with an rm on it to delete these files.  Test it carefully first.

But if you answered gotnull's question people might be able to help more.


----------



## Alain De Vos (Sunday at 11:20 PM)

Diskspace is cheap today. You can leave them around just in case.


----------



## richardtoohey2 (Sunday at 11:51 PM)

Alain De Vos said:


> You can leave them around just in case.


OP’s concern is that multiple instances of tor are starting up, not the disk space wasted.


----------



## Eric A. Borisch (Sunday at 11:51 PM)

ziomario said:


> It makes no sense for me. I don't see the utility of having duplicated executable files,rather it creates troubles to me. So,I would like to disable the pkgsave feature for the executable files. Instead,I see that this feature is ok for the config. files.



Again, it should not be creating these, except for files it did not expect to see that it now needs to replace when installing. If the files were from a prior package, it would not create these (since it would be deleting the prior ones first). Hence the question above of if these files were somehow installed manually previously.


----------



## ziomario (Monday at 9:57 AM)

Eric A. Borisch said:


> Again, it should not be creating these, except for files it did not expect to see that it now needs to replace when installing. If the files were from a prior package, it would not create these (since it would be deleting the prior ones first). Hence the question above of if these files were somehow installed manually previously.



what it means "installed manually" ? Concerning tor,I have configured it following some stray tutorial found here. Anyway tor is not the only executable file that's executed two times. Some time ago the same is happened with different executables,even with apache. If this happens sometime ok,I can remove the duplicated file easily,if it produces a lot of duplicated executables it should be stopped now,because the system will not work at all anymore. It could even complicated understand which pkgsave file is connected to a configuration file and which is connected to an executable.


----------



## VladiBG (Monday at 11:47 AM)

When you are installing a program using "pkg" during the extract of the pkg if there's a file conflict the pkg will rename the old file to .pkgsave and will not overwrite it (delete it).
At some point if you are manually installed a software let's say apache24 from it's source code and then manually created /usr/local/etc/rc.d/apache24 to start it as a service and then if you install again apache24 via pkg it will not replace already configured by you the apache24 file instead it will rename it as apache24.pkgsave and will retain it's file attributes aka will keep it as 755 (rwxr-xr-x) therefor you will end up with two files in /usr/local/etc/rc.d one is the apache24 extracted from the pkg and apache24.pkgsave which was your original file created by you. Same may happen if your pkg database is deleted (which is very bad thing)  and then pkg will not know what pkg are installed previously by itself and will preserve all files that are already installed as pkgsave.


----------



## ziomario (Tuesday at 12:48 PM)

---> you will end up with two files in /usr/local/etc/rc.d one is the apache24 extracted from the pkg and apache24.pkgsave which was your original file created by you.

that's what I don't want to happen. I prefer that the new executable overwrite the older one or that the new executable is copied as pkgsave,but it should not be +x. It's ok if it makes a backup of the configuration files connected to that executable.


----------



## VladiBG (Tuesday at 1:14 PM)

It's up to you to delete those .pkgsave files. You can use "find" to search for all files which end on .pkgsave


----------



## SirDice (Tuesday at 3:14 PM)

ziomario said:


> Concerning tor,I have configured it following some stray tutorial found here. Anyway tor is not the only executable file that's executed two times. Some time ago the same is happened with different executables,even with apache. If this happens sometime ok,I can remove the duplicated file easily,if it produces a lot of duplicated executables it should be stopped now,because the system will not work at all anymore.


Something else is going on. I can make 10 copies of /usr/local/bin/ntpd (for example) named ntpd.1, ntpd.2, etc. and leave all of them executable. That still won't spawn 10 copies of ntpd when I start the service. It doesn't matter how many copies you have of some executable, they're not going to get executed when you boot the system. That's not how things work, at all. Executables aren't spontaneously started if nothing calls them.


----------



## ziomario (Tuesday at 3:15 PM)

VladiBG,why don't you get the habit to read some older messages ? It's annoying that I should repeat again again concepts that I have already told before (comment #17). And its easy to catch you that you didn't do that . Anyway. It happened that the executables created were a lot,so my system messed up totally. Even if I wrote a script to remove every pkgsave,it should understand which one is executable from which one isn't. It's not an easy task for me.


----------



## SirDice (Tuesday at 3:22 PM)

ziomario said:


> It happened that the executables created were a lot,so my system messed up totally.


I'm not doubting your system is screwed up, but the .pkgsave files have nothing to do with that. They are NOT the cause of your problems.


----------



## ziomario (Tuesday at 3:23 PM)

SirDice said:


> Something else is going on. I can make 10 copies of /usr/local/bin/ntpd (for example) named ntpd.1, ntpd.2, etc. and leave all of them executable. That still won't spawn 10 copies of ntpd when I start the service. It doesn't matter how many copies you have of some executable, they're not going to get executed when you boot the system. That's not how things work, at all. Executables aren't spontaneously started if nothing calls them.



Carefully look at this example :


```
# find /usr -name "tor*.pkgsave" -print

/usr/local/bin/tor.pkgsave
/usr/local/etc/rc.d/tor.pkgsave

# find /usr -name "tor" -print

/usr/local/bin/tor
/usr/local/etc/rc.d/tor
```

I had 4 legit executable which ran. I think this could happen because the system thinks that tor.pkgsave file is the same as the tor executable and it allowed to run it. If it does not work like this,I don't know.


----------



## SirDice (Tuesday at 3:24 PM)

ziomario said:


> I had 4 legit executable which ran.


You have two rc(8) scripts. That's causing it to get started twice.



ziomario said:


> I think this could happen because the system thinks that tor.pkgsave file is the same as the tor executable and it allowed to run it.


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.

Simple solution: `find / -type f -name '*.pkgsave' -delete`


----------



## VladiBG (Tuesday at 3:24 PM)

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.


----------



## ziomario (Tuesday at 3:26 PM)

SirDice said:


> 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.


----------



## SirDice (Tuesday at 3:29 PM)

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.


----------



## ziomario (Tuesday at 6:10 PM)

SirDice said:


> 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.


----------



## SirDice (Tuesday at 6:12 PM)

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).


----------



## ziomario (Tuesday at 6:28 PM)

We can get these files as an example :


```
/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 ?


----------



## SirDice (Tuesday at 6:40 PM)

ziomario said:


> 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. 



ziomario said:


> 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.


----------



## Eric A. Borisch (Wednesday at 1:51 AM)

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 …_


----------



## smithi (Wednesday at 3:08 AM)

SirDice said:


> 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.





ziomario said:


> 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.


----------



## aragats (Wednesday at 3:40 AM)

SirDice said:


> 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.


----------



## SirDice (Wednesday at 9:08 AM)

aragats said:


> 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?



aragats said:


> 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.


----------



## smithi (Wednesday at 11:05 AM)

SirDice said:


> 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?


----------



## SirDice (Wednesday at 11:28 AM)

Yes, there's some logic that detects the old style *.sh scripts and to filter backup and RCS files.


```
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.


----------



## ziomario (Wednesday at 1:28 PM)

SirDice said:


> 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.


----------



## SirDice (Wednesday at 1:34 PM)

ziomario said:


> 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.


----------



## ziomario (Wednesday at 1:41 PM)

SirDice said:


> 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.


----------



## SirDice (Wednesday at 1:43 PM)

ziomario said:


> what's the problem with my approach ? I don't understand this.


Your own argument:


ziomario said:


> 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. 



ziomario said:


> 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).


ziomario said:


> 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. 



ziomario said:


> 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. 


```
-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
```


```
-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
             (“\”).
```


```
-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.
```


----------



## ziomario (Wednesday at 1:51 PM)

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.


----------



## SirDice (Wednesday at 2:07 PM)

ziomario said:


> 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.



ziomario said:


> 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.


----------



## ziomario (Wednesday at 3:00 PM)

Ohhh. You are talking about this script :


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

and not about this :


```
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.


----------



## ziomario (Wednesday at 3:05 PM)

And anyway. I understand this easy command line :


```
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.


----------



## SirDice (Wednesday at 3:08 PM)

ziomario said:


> 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`).


----------



## ziomario (Wednesday at 3:14 PM)

SirDice said:


> 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 ?


----------



## SirDice (Wednesday at 3:16 PM)

ziomario said:


> You haven't fixed anything,right ?


Correct, the part I copy/pasted is 'vanilla', I didn't make any changes to it.


----------



## ziomario (Wednesday at 3:17 PM)

SirDice said:


> Correct, the part I copy/pasted is 'vanilla', I didn't make any changes to it.



ok. So,at the moment I'm / we are without a satisfactory solution.


----------



## SirDice (Wednesday at 3:20 PM)

Really, just file a PR for it. Then it can be changed in the OS and everyone benefits from it. You have good arguments to get this added. And, it'll be your contribution to the FreeBSD OS, how does that sound?


----------



## ziomario (Wednesday at 3:41 PM)

> 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).



I trust in you. If you say that this particular behavior is not a real problem for a lot of very well maintained systems,I will not file any PR. It means that I've tried to fix my previous broken system using my imagination (and it worked),but this creates not expected situations,that no one else will find in the future. If you want to file a PR,you can do it. For me is enough if you would like to complete the script that I have asked,adding the filter for detecting the pkgsave executable files to the command line that you have already wrote :


```
find /usr/local -type f -name '*.pkgsave' -filter executable files only
```


----------



## SirDice (Wednesday at 4:09 PM)

ziomario said:


> For me is enough if you would like to complete the script that I have asked,adding the filter for detecting the pkgsave executable files to the command line that you have already wrote :


Well, this shows I'm not _that_ experienced with find(1) and I need to try and test whatever I come up with. I always get royally confused with the `-perm` option.  

I think this might do it: `find /usr/local/ -type f -name '*.pkgsave' -perm +a+x`


```
-perm [-|+]mode
             The mode may be either symbolic (see chmod(1)) or an octal
             number.  If the mode is symbolic, a starting value of zero is
             assumed and the mode sets or clears permissions without regard to
             the process' file mode creation mask.  If the mode is octal, only
             bits 07777 (S_ISUID | S_ISGID | S_ISTXT | S_IRWXU | S_IRWXG |
             S_IRWXO) of the file's mode bits participate in the comparison.
             If the mode is preceded by a dash (“-”), this primary evaluates
             to true if at least all of the bits in the mode are set in the
             file's mode bits.  If the mode is preceded by a plus (“+”), this
             primary evaluates to true if any of the bits in the mode are set
             in the file's mode bits.  Otherwise, this primary evaluates to
             true if the bits in the mode exactly match the file's mode bits.
             Note, the first character of a symbolic mode may not be a dash
             (“-”).
```


----------



## ziomario (Wednesday at 5:13 PM)

I have a LOT of pkgsave's executable files on /usr/local,but I see that none of them is executed when FreeBSD starts. So,the directories to scan are only /usr/local/etc/rc.d/ and /etc/rc.d ?

This list seems to contains exactly the files that I should remove :


```
# find /usr/local/etc/rc.d -type f -name '*.pkgsave' -perm +a+x

/usr/local/etc/rc.d/openvpn.pkgsave
/usr/local/etc/rc.d/avahi-dnsconfd.pkgsave
/usr/local/etc/rc.d/avahi-daemon.pkgsave
/usr/local/etc/rc.d/cupsd.pkgsave
/usr/local/etc/rc.d/uuidd.pkgsave
/usr/local/etc/rc.d/cbsdd.pkgsave
/usr/local/etc/rc.d/cbsd-statsd-jail.pkgsave
/usr/local/etc/rc.d/cbsdrsyncd.pkgsave
/usr/local/etc/rc.d/cbsd-statsd-hoster.pkgsave
/usr/local/etc/rc.d/dbus.pkgsave
/usr/local/etc/rc.d/cbsd-statsd-bhyve.pkgsave
```

Instead,I have no files on /etc/rc.d


----------



## SirDice (Wednesday at 5:23 PM)

ziomario said:


> I have a LOT of pkgsave's executable files on /usr/local,but I see that none of them is executed when FreeBSD starts.


You still want to remove those, it just clutters the system, taking up space for absolutely no reason. 



ziomario said:


> So,the directories to scan are only /usr/local/etc/rc.d/ and /etc/rc.d ?


Those are the only two directories where services are started from during boot. Technically speaking you need to look at /etc/rc.d and whatever directories have been set in `local_startup` (see /etc/defaults/rc.conf). But most people simply use the default and have this set to /usr/local/etc/rc.d.


----------



## ziomario (Wednesday at 8:41 PM)

Now I'm thinking to remove every *.pkgsave file from the system. So,the command that I will issue is the following :


```
# find / -type f -name '*.pkgsave' -delete
```

Will this operation mess up the system ?


----------



## smithi (Wednesday at 8:45 PM)

ziomario said:


> ok. So,at the moment I'm / we are without a satisfactory solution.



Did you really not see my post #34 where I offered an alternative final clause for SirDice's find command, that instead of deleting the *.pkgsave files, just cleared their executable flags?

That would leave them in place (as you said you want) but prevent them from being run by the rc system (which you found was a problem)?


----------



## ziomario (Wednesday at 9:19 PM)

Sure man,I seen your command on post #34,this one :

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

but :

1) the annoying executable files are located only on* /usr/local/etc/rc.d* and I have already removed them,copying them on another directory

2) actually my goal is to free space from the whole disk. If you tell to me that my system will continue to work great if I remove every *.pkgsave file stored on the disk,I will do it.


----------



## eternal_noob (Wednesday at 9:56 PM)

SirDice said:


> On a properly maintained system those files shouldn't get created in the first place.





SirDice said:


> You have good arguments to get this added.


Mutual exclusivity at its finest.


----------



## smithi (Thursday at 5:09 AM)

"Give a man a fish and you feed him for a day. Teach him how to fish and you feed him for a lifetime”
    -- Lao Tzu


----------



## ziomario (Thursday at 3:30 PM)

smithi said:


> "Give a man a fish and you feed him for a day. Teach him how to fish and you feed him for a lifetime”
> -- Lao Tzu



"Tell a fisher to read the man page and you hurt him for a day. Ask him how to fish and you have found a new friend for the lifetime". Mario Zio.


----------



## ziomario (Thursday at 3:32 PM)

eternal_noob said:


> Mutual exclusivity at its finest.



Can you elaborate a little bit more ? what do you mean with "mutual exclusivity at its finest" ? thanks bro.


----------



## ziomario (Thursday at 3:40 PM)

I would ask you a suggestion. Since my main FreeBSD system is not working well,'cause the problem that I have explained here :






						r/freebsd - Comment by u/12Darius21 on ”My current FreeBSD installation does not take care at all of the /boot/loader.conf's commented lines.”
					

10 votes and 4 comments so far on Reddit




					www.reddit.com
				




I suspect that the problem is tied to the massive presence of the *.pkgsave files located everywhere between the regular FreeBSD system files. In particular,I suspect that some *.pkgsave files that are connected to some regular configuration files interfere with them. For example,it / they could interfere with the regular working of the */boot/loader.conf*. Is that possible ?


----------



## eternal_noob (Thursday at 5:18 PM)

ziomario said:


> what do you mean with "mutual exclusivity at its finest"


This means that things can't happen at the same time. I find the posts i quoted quite the contrary.


----------



## ziomario (Thursday at 5:42 PM)

eternal_noob said:


> This means that things can't happen at the same time. I find the posts i quoted quite the contrary.



Its too hard for me to understand you. Your language sometimes sounds to me a little bit cryptic.


----------



## eternal_noob (Thursday at 6:27 PM)

I just wanted to say that filing a PR is not appropriate in this case because the problem does not appear on well maintained systems.


----------



## ziomario (Thursday at 11:25 PM)

eternal_noob said:


> I just wanted to say that filing a PR is not appropriate in this case because the problem does not appear on well maintained systems.



explain to me what to do to "file a PR".


----------



## Eric A. Borisch (Thursday at 11:56 PM)

Bug Reports
					

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.




					www.freebsd.org


----------



## SirDice (Yesterday at 11:41 AM)

eternal_noob said:


> Mutual exclusivity at its finest.


Not really. If you maintain a system properly and don't muck around with the package database then you won't get those files. That said, people make mistakes and screw up, this thread is testament of that. It's a relatively simple change that would prevent some potential disastrous consequences if you do happen to screw up your system this way.


----------

