-
Notifications
You must be signed in to change notification settings - Fork 23
RPM package zeros out log file on upgrade #374
Comments
I think that maybe the assumption being made is that RPM needs to show that the log file is owned by the package when I don't believe this is a requirement. On my system I actually show a few that have ownership but I really think that is an exception. See attachment, output.txt. |
Upgrade from 2017.7.0 to 2017.7.1 still zero-ing out log files. The following is the /var/log/salt/ directory before the upgrade.
The following is the /var/log/salt/ directory after the upgrade.
Note that the logs master and minion are now either zero length or have been reset from zero-on. |
This is still an issue. I just now downgraded my Master from 3000.3.1 to 3000.2.1 (trying to work around another issue, saltstack/salt#57750) and my /var/log/salt/master file was zero'ed out as part of the process. It is normal for RPMs to take ownership of subdirectories that are made in the system, like /var/log/salt/ for instance, however it is not normal (or necessary) for an RPM to take ownership of individual log files. As an example (Red Hat Apache RPM:)
I would highly recommend removing the following lines from the SPEC files.
This is causing RPM to consider these files to be created by the RPM packaging process rather than the Salt Master or Minion apps and in this way produces zero-byte files which wipe out the previous files on the filesystem when upgrading. |
Actually after digging through the documentation for SPEC files, if you still want to have explicit entries in the RPM for these log files, I believe it would probably be more appropriate to move each individual log file entry, This is described here https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html-single/RPM_Guide/index.html
The MAN page for RPM specifies this similarly as shown here https://linux.die.net/man/8/rpm (note the description of GHOST)
I believe I guess, time permitting, I will try to patch this SPEC and generate a pull request... |
when you make the pr, make it on the salt-pack-py3 repo in the master folder too. This repo is for python 2 and other than CVE releases, all new builds will be python3 only. 3001 was python3 only for example. |
I believe the /var/log/salt/master and /var/log/salt/minion files are likely included in the RPM package(s) as a zero-length file and thus wipe out an already-existing log file on install/upgrade.
I upgraded from 2016.11.6 to 2017.7.0 just moments ago and saw this during the upgrade:
I would expect it to act like other packages and not wipe out the log file(s). I think this should be done with specific flags in the RPM spec-file rather than packaging a zero-length file. As it is, we lose any logged entries prior to the install/update.
The text was updated successfully, but these errors were encountered: