mainstoreBackup - Support: sr #110508, Use of uninitialized value...


sr #110508: Use of uninitialized value $ENV{"USER"}

Submitter:  None
Submitted:  Fri 11 Jun 2021 08:30:47 AM UTC
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  None
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Tue 28 Jun 2022 06:14:05 PM UTC, comment #8: 

new code in version 3.5.3

my $lockFile = (getpwuid($<))[0] eq 'root' ?     # default value
    '/var/lock/storeBackup.lock' :
    (getpwuid($<))[7] . '/storeBackup.lock';

Heinz-Josef Claes <hjclaes>
Group administrator
Sun 26 Jun 2022 01:58:48 PM UTC, comment #7: 


since I found no 'non-public' way for communicating a mail-address to you (and spam being an ever growing problem, since more than twenty years), you may need to add the host-part of owl-soft DOT de to my name yourself. ;)

Lock-File-Logic sounds like a fun topic to wrap your head around. I'm looking forward to that conversation. Be warned though, I'm not a developer and am dealing with this technology mainly out of my own curiosity.



Sat 25 Jun 2022 01:33:21 PM UTC, comment #6: 

a long time ago (before your email) I had a conversation about this with someone from SUSE. His point was the location,(/var/lock), of my easy way for a non-root user to make a backup.

We agreed on:

my $lockFile = ($ENV{'USER'} eq 'root') ?     # default value
                '/var/lock/storeBackup.lock' :
                $ENV{'HOME'} . '/storeBackup.lock';

We should build in your correction about the missing $HOME.,,,
I see lockfiles in connection with storeBackup as unsatisfactorily solved.
Maybe we shouldn't just offer one scenario (like the simple one above)? With something like your logic? More information in the lockfile? And an option to switch between these?

Can you send me your e-mail address?

Best regards,
Heinz Josef

Heinz-Josef Claes <hjclaes>
Group administrator
Fri 24 Jun 2022 04:57:55 PM UTC, comment #5: 


I just happily realized, that there is a new release available (3.5.2). However I could not find a mentioning of this issue in the changelog. Is this fixed already? Or was this postponed to a later version. (Which is fine to me, since I have a working workaround.)

Kind Regards,


Fri 11 Jun 2021 01:17:03 PM UTC, comment #4: 


of course it's ok with the next version. By no means did I want to hurry you to anything. Putting an extra line in my wrapper script wasn't that hard. ;)

I also get the problem with /tmp/storeBackup.lock on a multi-user-system. Which is a use case I didn't think about, since on my servers the users don't get shell-access. But it's interesting that even SUSE has interest in this project.



Fri 11 Jun 2021 12:44:35 PM UTC, comment #3: 

It's better to do it that way, of course. I will adjust this in the next version (I hope this is ok!?).

The request for the change came from SUSE, because the old variant of writing the lock file to /tmp/storeBackup.lock allows a denial of service attack (and doesn't allow e.g. two users to backup at the same time).

The problem with the cron jobs probably slipped through my fingers.

Heinz-Josef Claes <hjclaes>
Group administrator
Fri 11 Jun 2021 10:12:42 AM UTC, comment #2: 


of course it's easy to just set the variable beforehand. But is it a good idea to rely on a variable, that in a lot of cases (I bet I'm not the only one running this as a cronjob) is not present? The next thing that probably also isn't set is $HOME.

I'm not a perl developer, so I can't speak to the quality of the following, but a quick google search [1] revealed a solution using:

my $username = getpwuid( $< );

Which seams pretty handy as it can also reveal the home directory [2]:

This function returns the password file entry for the user ID $id.


# get user info
($name, $pass, $uid, $gid, $quota, $comment, $gcos, $dir, $shell, $expire) = getpwuid(1000);

By the way, was there a specific reason to move the default lockFile location? Of the top of my head I can't see a problem with the old default being in /tmp, which should be usable by everybody. But I'm probably missing something.

I guess I found the reason why my backups still work. I explicitly set the lockFile location in the config-files. So the location is not dependent on the actual outcome of the evaluation of the env-var.




Fri 11 Jun 2021 09:33:46 AM UTC, comment #1: 


the environment variable "USER" is needed to set the lock file differently for root and other users. (Writing it to /var/lock for non-root users causes permissions problems in some distributions).
If the variable is not set (this happens mainly in cron jobs) please export it e.g. simply with
export USER=root
before calling storeBackup.


Heinz-Josef Claes <hjclaes>
Group administrator
Fri 11 Jun 2021 08:30:47 AM UTC, original submission:  


since I upgraded to 3.5.1 two days ago, I get the following error on my clients:

Use of uninitialized value $ENV{"USER"} in string eq at /usr/local/bin/ line 136.

I also get a very similar error on the server:

Use of uninitialized value $ENV{"USER"} in string eq at /usr/local/bin/ line 104.

The server is running Debian 10, the clients are Debian 10 and 11, Ubuntu 18.04 and 20.04, Raspbian 10 and Linux Mint 19. Clients do there backups to an isolated pool with lateLinks and the server then does the merge and update part. I can provide a sample config-file (they are all basically the same apart from the series name) if that helps. But I think this is more of a general problem.

The fun thing is: The backups still work, are complete and valid. The merging and update also works, even though I get that error.

From what I found, this problem seams to only appear when storeBackup runs as a cronjob. The crontab looks like this:


# m h dom mon dow user command
/15 7-23        root  /usr/bin/nice -n 10 /usr/local/bin/

The wrapper script does quite a lot of stuff before the actual backup begins, but nothing that is user specific or messes with environment variables. In the end it just calls:

/usr/local/bin/ -f $conffile

Other things the wrapper script does:
- Check if there has been a successful backup in the last N hours (skip if so)
- Check if the last backup was successful (rerun if not)
- Check if storeBackup is already running (abort if so)
- Check for availability of the server
- Check for updated config files

I need to, one day, get this script in a proper git repository and proper shape to make that public I guess.

So I'm not entirely sure, this is actually a problem with storeBackup 3.5.1 or maybe just my setup. All I know is that I didn't have any errors with 3.5.





(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by hjclaes (Posted a comment)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-ee12.
    Corresponding source code