Attached is a small patch against the RHEL/CentOS fschwarz
bacula-client-3.0.2-1.x86_64 init script. My apologies that I'm not
set up for git right now, so I'm not sure if this has already been
fixed in a newer version.
This fixes a problem where, if you have more than one bacula-fd running,
then 'service bacula-fd status' and 'service bacula-fd stop' will
improperly kill *all* bacula-fd instances instead of just the one started
by the script.
I ran into this when I had most filesystem backed up by the main bacula-fd
controlled by the init script, but also had additional bacula-fd processes
for Linux-HA clustered filesystems.
The patch is also available at
ftp://ftp.gno.org/pub/tools/bacula-contrib
See the README for details.
Devin
--
Shirt, Shoes, Sober... --Pick Two
- Chuck Yerkes

On 12/29/2010 2:06 PM, Martin Simmons wrote:
>>>>>> On Tue, 28 Dec 2010 10:28:05 -0300, Victor Hugo dos Santos said:
>>
>> A question:
>> In this case (gvfs) is mounted in /home/user/.gvfs and is a different
>> filesystem.
>> so, if I configure my filseset to backup "/home/user", for default
>> bacula should ignore all mounted filesystems inside of /home/user o
>> not ??
>
> Yes, it will ignore them but sadly I think it will still give a warning.
>
> Bacula detects when the filesystem is different by looking at the st_dev value
> in the stat structure, but stat is failing because of FUDE.
According to http://marc.info/?l=bacula-devel&m=129318292021117&w=2 the
message in question is:
23-Dec 22:00 totem-fd JobId 107: Could not stat "/home/scan/.gvfs": \
ERR=Permission denied
As Martin mentions, there is no way for Bacula to read .gvfs and
therefore *detect* that this is a different filesystem.
As mentioned in my previous post, you can tell Bacula to ignore all
files (or directories) named .gvfs. I think this is your best option.
--
Dan Langille - http://langille.org/

>>>>> On Tue, 28 Dec 2010 10:28:05 -0300, Victor Hugo dos Santos said:
>
> A question:
> In this case (gvfs) is mounted in /home/user/.gvfs and is a different
> filesystem.
> so, if I configure my filseset to backup "/home/user", for default
> bacula should ignore all mounted filesystems inside of /home/user o
> not ??
Yes, it will ignore them but sadly I think it will still give a warning.
Bacula detects when the filesystem is different by looking at the st_dev value
in the stat structure, but stat is failing because of FUDE.
__Martin

On Tue, Dec 28, 2010 at 8:04 PM, Dan Langille <dan@...> wrote:
> On 12/28/2010 8:28 AM, Victor Hugo dos Santos wrote:
>>
>> On Mon, Dec 27, 2010 at 12:40 PM, Martin Simmons<martin@...>
>> wrote:
>>>>>>>>
>>>>>>>> On Fri, 24 Dec 2010 21:34:58 -0500, Dan Langille said:
>>
>> [...]
>>
>>>> How do these people propose that such a system be backed up?
>>>
>>> There is nothing in the .gvfs directory that needs to be backed up -- it
>>> contains mounts for external resources and is recreated by the system
>>> from
>>> metadata.
>>
>> good point !! :D
>>
>> A question:
>> In this case (gvfs) is mounted in /home/user/.gvfs and is a different
>> filesystem.
>> so, if I configure my filseset to backup "/home/user", for default
>> bacula should ignore all mounted filesystems inside of /home/user o
>> not ??
>
> If the objective is to not backup any directory which contains .gvfs, then
> look at the File Set options which allow you to exclude a directory which
> contains a given file name.
>
> Look for: ExcludeDirContaining
>
> Is that what you need? Hmm, .gfvs is a directory... might work.. but
> nothing in that directory will be backed up. I mean, in your example,
> nothing in /home/user would be backed up.
Hello Dan Langille,
sorry, maybe I don't explain very well.
/home/user/.gvfs is a directory, but it is a ohter filesystem
(fuse.gvfs-fuse-daemon) mounted in "/home/user".
This the output of mount command:
$ mount
/dev/mapper/VG_DATOS-vhs--home on /home type reiserfs (rw)
encfs on /home/victor type fuse.encfs
(rw,nosuid,nodev,default_permissions,allow_other,user=victor)
gvfs-fuse-daemon on /home/victor/.gvfs type fuse.gvfs-fuse-daemon
(rw,nosuid,nodev,user=victor)
and my question was:
if I have 3 filesystem
/dev/sdb1 = /home/alice
/dev/sdc1 = /home/bob
/dev/sdd1 = /home/pepe
for default, bacula don't descend in subdirectories that are a
different filesystem. In the example above, we need configure the
FileSet to backup "/home" directory and need indicate the others
subdirectories, for example:
=============
FileSet {
Name = "homes"
Include {
Options { signature = SHA1; compression=GZIP5 }
File = /home
File = /home/alice
File = /home/bob
File = /home/pepe
}
}
=============
For default, the .gvfs directories should be ignored by bacula and
only show a alert (/home/scan/.gvfs is a different filesystem. Will
not descend"). Som why bacula try to backup the /home/scan/.gvfs if
this is a different filesystem ??
Note.: In the original message don't show that /home/scan/.gvfs is a
other mounted filesystem, but I believe that it is.
bye
--
--
Victor Hugo dos Santos
Linux Counter #224399

On 12/28/2010 8:28 AM, Victor Hugo dos Santos wrote:
> On Mon, Dec 27, 2010 at 12:40 PM, Martin Simmons<martin@...> wrote:
>>>>>>> On Fri, 24 Dec 2010 21:34:58 -0500, Dan Langille said:
>
> [...]
>
>>> How do these people propose that such a system be backed up?
>>
>> There is nothing in the .gvfs directory that needs to be backed up -- it
>> contains mounts for external resources and is recreated by the system from
>> metadata.
>
> good point !! :D
>
> A question:
> In this case (gvfs) is mounted in /home/user/.gvfs and is a different
> filesystem.
> so, if I configure my filseset to backup "/home/user", for default
> bacula should ignore all mounted filesystems inside of /home/user o
> not ??
If the objective is to not backup any directory which contains .gvfs,
then look at the File Set options which allow you to exclude a directory
which contains a given file name.
Look for: ExcludeDirContaining
Is that what you need? Hmm, .gfvs is a directory... might work.. but
nothing in that directory will be backed up. I mean, in your example,
nothing in /home/user would be backed up.
Perhaps all you need is:
File = .gvfs
--
Dan Langille - http://langille.org/

On Mon, Dec 27, 2010 at 12:40 PM, Martin Simmons <martin@...> wrote:
>>>>>> On Fri, 24 Dec 2010 21:34:58 -0500, Dan Langille said:
[...]
>> How do these people propose that such a system be backed up?
>
> There is nothing in the .gvfs directory that needs to be backed up -- it
> contains mounts for external resources and is recreated by the system from
> metadata.
good point !! :D
A question:
In this case (gvfs) is mounted in /home/user/.gvfs and is a different
filesystem.
so, if I configure my filseset to backup "/home/user", for default
bacula should ignore all mounted filesystems inside of /home/user o
not ??
bye
--
--
Victor Hugo dos Santos
Linux Counter #224399

On Fri, Dec 24, 2010 at 11:34 PM, Dan Langille <dan@...> wrote:
[...]
> How do these people propose that such a system be backed up?
> It's kind of silly, considering root can su to a given user.
Hello,
In my case I use the encfs + fuse for encrypt my home folder.
so.. I have two folders
/home/pepe-CRYPT (here is the encrypted files)
/home/pepe (here is the decrypted files)
in my case only the user "pepe" have access to "/home/pepe", but all
other users can access "/home/pepe-CRYPT".
so, in my case I backup the "/home/pepe-CRYPT".
Obs.: Is possible to specific that others users (option allow_other)
will be access to "/home/pepe", but I prefer backup the information
from "/home/pepe-CRYPT" because there are encrypted.
bye
--
--
Victor Hugo dos Santos
Linux Counter #224399

On 12/27/2010 04:40 PM, Martin Simmons wrote:
>>>>>> On Fri, 24 Dec 2010 21:34:58 -0500, Dan Langille said:
>>
>> On 12/24/2010 7:51 AM, Bruno Friedmann wrote:
>>> On 12/24/2010 01:48 PM, Kern Sibbald wrote:
>>>> On Friday 24 December 2010 12:54:00 Martin Simmons wrote:
>>>>>>>>>> On Fri, 24 Dec 2010 10:28:22 +0100, Bruno Friedmann said:
>>>>>>
>>>>>> Hi there,
>>>>>>
>>>>>> With the onefs = no shouldn't gvfs mounting point considered as external
>>>>>> filesystem.
>>>>>>
>>>>>> I got this warning on workstation or server when user's have let their X
>>>>>> gnome session open and perharps use one gvfs ressource open ( nautilus
>>>>>> smb://server/share for example )
>>>>>>
>>>>>> 23-Dec 22:00 totem-fd JobId 107: Could not stat "/home/scan/.gvfs":
>>>>>> ERR=Permission denied
>>>>>>
>>>>>> Hopefully bacula-fd ( running as root can't access this folder )
>>>>>> otherwise, it will be able to save remote data that gvfs can access ...
>>>>>>
>>>>>> If you agree that should be changed, I can open a bug request to that ...
>>>>>
>>>>> For security reasons, only the owner can read the .gvfs directory, so the
>>>>> bacula-fd gets ERR=Permission denied when it runs as root.
>>>>
>>>> Interesting, so root is no longer totally powerful. Hmmm.
>>>
>>> Yes Kern, some people on the Gnome world has been inspirited by other "crappy OS" where God is no more God.
>>> :-)
>>
>> How do these people propose that such a system be backed up?
>
> There is nothing in the .gvfs directory that needs to be backed up -- it
> contains mounts for external resources and is recreated by the system from
> metadata.
>
>
>> It's kind of silly, considering root can su to a given user.
>
> Yes, but only if it explicitly does that. The .gvfs filesystem is implemented
> as a userland process (via FUSE), so giving access to root would
> surreptitiously run code as another user, possibly passing those credentials
> to remote servers. That could break other security measures such as nfs
> maproot.
>
> __Martin
>
Didn't know how user jobs can react but you can always ask a umount as root
gvfs-fuse-daemon on /home/bruno/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,relatime,user_id=1502,group_id=1500)
umount gvfs-fuse-daemon
Anyway, I've added this path in my normal excluded wild
--
Bruno Friedmann (irc:tigerfoot)
Ioda-Net Sàrl http://www.ioda-net.ch
openSUSE Member
User http://www.ioda.net/r/osu
Blog http://www.ioda.net/r/blog
fsfe fellowship http://www.fsfe.org
GPG KEY : D5C9B751C4653227
vcard : http://it.ioda-net.ch/ioda-net.vcf

>>>>> On Fri, 24 Dec 2010 21:34:58 -0500, Dan Langille said:
>
> On 12/24/2010 7:51 AM, Bruno Friedmann wrote:
> > On 12/24/2010 01:48 PM, Kern Sibbald wrote:
> >> On Friday 24 December 2010 12:54:00 Martin Simmons wrote:
> >>>>>>>> On Fri, 24 Dec 2010 10:28:22 +0100, Bruno Friedmann said:
> >>>>
> >>>> Hi there,
> >>>>
> >>>> With the onefs = no shouldn't gvfs mounting point considered as external
> >>>> filesystem.
> >>>>
> >>>> I got this warning on workstation or server when user's have let their X
> >>>> gnome session open and perharps use one gvfs ressource open ( nautilus
> >>>> smb://server/share for example )
> >>>>
> >>>> 23-Dec 22:00 totem-fd JobId 107: Could not stat "/home/scan/.gvfs":
> >>>> ERR=Permission denied
> >>>>
> >>>> Hopefully bacula-fd ( running as root can't access this folder )
> >>>> otherwise, it will be able to save remote data that gvfs can access ...
> >>>>
> >>>> If you agree that should be changed, I can open a bug request to that ...
> >>>
> >>> For security reasons, only the owner can read the .gvfs directory, so the
> >>> bacula-fd gets ERR=Permission denied when it runs as root.
> >>
> >> Interesting, so root is no longer totally powerful. Hmmm.
> >
> > Yes Kern, some people on the Gnome world has been inspirited by other "crappy OS" where God is no more God.
> > :-)
>
> How do these people propose that such a system be backed up?
There is nothing in the .gvfs directory that needs to be backed up -- it
contains mounts for external resources and is recreated by the system from
metadata.
> It's kind of silly, considering root can su to a given user.
Yes, but only if it explicitly does that. The .gvfs filesystem is implemented
as a userland process (via FUSE), so giving access to root would
surreptitiously run code as another user, possibly passing those credentials
to remote servers. That could break other security measures such as nfs
maproot.
__Martin

On 12/24/10 21:34, Dan Langille wrote:
> On 12/24/2010 7:51 AM, Bruno Friedmann wrote:
>> On 12/24/2010 01:48 PM, Kern Sibbald wrote:
>>> On Friday 24 December 2010 12:54:00 Martin Simmons wrote:
>>>> For security reasons, only the owner can read the .gvfs directory, so the
>>>> bacula-fd gets ERR=Permission denied when it runs as root.
>>>
>>> Interesting, so root is no longer totally powerful. Hmmm.
>>
>> Yes Kern, some people on the Gnome world has been inspirited by other "crappy OS" where God is no more God.
>> :-)
>
> How do these people propose that such a system be backed up?
>
> It's kind of silly, considering root can su to a given user.
Unfortunately, Gnome not only seems to be the repository for every
half-baked idea by every CS junior on the planet, it is gradually
metastasizing into every part of not just Linux, but even other OSen.
It wouldn't be the first time the ideas have been as poorly thought
through as this one.
--
Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355
alaric@... alaric@... phil@...
Renaissance Man, Unix ronin, Perl hacker, Free Stater
It's not the years, it's the mileage.

On 12/24/2010 7:51 AM, Bruno Friedmann wrote:
> On 12/24/2010 01:48 PM, Kern Sibbald wrote:
>> On Friday 24 December 2010 12:54:00 Martin Simmons wrote:
>>>>>>>> On Fri, 24 Dec 2010 10:28:22 +0100, Bruno Friedmann said:
>>>>
>>>> Hi there,
>>>>
>>>> With the onefs = no shouldn't gvfs mounting point considered as external
>>>> filesystem.
>>>>
>>>> I got this warning on workstation or server when user's have let their X
>>>> gnome session open and perharps use one gvfs ressource open ( nautilus
>>>> smb://server/share for example )
>>>>
>>>> 23-Dec 22:00 totem-fd JobId 107: Could not stat "/home/scan/.gvfs":
>>>> ERR=Permission denied
>>>>
>>>> Hopefully bacula-fd ( running as root can't access this folder )
>>>> otherwise, it will be able to save remote data that gvfs can access ...
>>>>
>>>> If you agree that should be changed, I can open a bug request to that ...
>>>
>>> For security reasons, only the owner can read the .gvfs directory, so the
>>> bacula-fd gets ERR=Permission denied when it runs as root.
>>
>> Interesting, so root is no longer totally powerful. Hmmm.
>
> Yes Kern, some people on the Gnome world has been inspirited by other "crappy OS" where God is no more God.
> :-)
How do these people propose that such a system be backed up?
It's kind of silly, considering root can su to a given user.
--
Dan Langille - http://langille.org/

>>>>> On Fri, 24 Dec 2010 13:48:46 +0100, Kern Sibbald said:
>
> On Friday 24 December 2010 12:54:00 Martin Simmons wrote:
>
> > For security reasons, only the owner can read the .gvfs directory, so the
> > bacula-fd gets ERR=Permission denied when it runs as root.
>
> Interesting, so root is no longer totally powerful. Hmmm.
The gvfs filesystem is implemented with fuse, which allows this kind of
restriction.
Of course there are other things like SELinux and FreeBSD Mandatory Access
Control that can restrain the power of root too.
__Martin

On 12/24/2010 01:48 PM, Kern Sibbald wrote:
> On Friday 24 December 2010 12:54:00 Martin Simmons wrote:
>>>>>>> On Fri, 24 Dec 2010 10:28:22 +0100, Bruno Friedmann said:
>>>
>>> Hi there,
>>>
>>> With the onefs = no shouldn't gvfs mounting point considered as external
>>> filesystem.
>>>
>>> I got this warning on workstation or server when user's have let their X
>>> gnome session open and perharps use one gvfs ressource open ( nautilus
>>> smb://server/share for example )
>>>
>>> 23-Dec 22:00 totem-fd JobId 107: Could not stat "/home/scan/.gvfs":
>>> ERR=Permission denied
>>>
>>> Hopefully bacula-fd ( running as root can't access this folder )
>>> otherwise, it will be able to save remote data that gvfs can access ...
>>>
>>> If you agree that should be changed, I can open a bug request to that ...
>>
>> For security reasons, only the owner can read the .gvfs directory, so the
>> bacula-fd gets ERR=Permission denied when it runs as root.
>
> Interesting, so root is no longer totally powerful. Hmmm.
Yes Kern, some people on the Gnome world has been inspirited by other "crappy OS" where God is no more God.
:-)
>
>>
>> It is difficult to avoid these errors because Bacula has to stat the file
>> before it can decide that it is in a different filesystem (or even exclude
>> it from the backup via the fileset definition).
ok I understand now how it works.
>>
>> __Martin
>>
That's how I will handle with a wild exclude about .gvfs ( fortunately, at this time it's always stored at the same place, with
the same name )
Merry Christmas to All.
--
Bruno Friedmann (irc:tigerfoot)
Ioda-Net Sàrl http://www.ioda-net.ch
openSUSE Member
User http://www.ioda.net/r/osu
Blog http://www.ioda.net/r/blog
fsfe fellowship http://www.fsfe.org
GPG KEY : D5C9B751C4653227
vcard : http://it.ioda-net.ch/ioda-net.vcf

On Friday 24 December 2010 10:28:22 Bruno Friedmann wrote:
> Hi there,
>
> With the onefs = no shouldn't gvfs mounting point considered as external
> filesystem.
>
> I got this warning on workstation or server when user's have let their X
> gnome session open and perharps use one gvfs ressource open ( nautilus
> smb://server/share for example )
>
> 23-Dec 22:00 totem-fd JobId 107: Could not stat "/home/scan/.gvfs":
> ERR=Permission denied
>
> Hopefully bacula-fd ( running as root can't access this folder ) otherwise,
> it will be able to save remote data that gvfs can access ...
>
> If you agree that should be changed, I can open a bug request to that ...
I don't see any indication of a bug here. Even with onefs = no, Bacula wants
to backup the directory entery. If it cannot stat the file, then you will
get an error.
I imagine you are running Bacula as non-root.
Regards,
Kern

>>>>> On Fri, 24 Dec 2010 10:28:22 +0100, Bruno Friedmann said:
>
> Hi there,
>
> With the onefs = no shouldn't gvfs mounting point considered as external filesystem.
>
> I got this warning on workstation or server when user's have let their X gnome session open and perharps use one gvfs ressource
> open ( nautilus smb://server/share for example )
>
> 23-Dec 22:00 totem-fd JobId 107: Could not stat "/home/scan/.gvfs": ERR=Permission denied
>
> Hopefully bacula-fd ( running as root can't access this folder ) otherwise, it will be able to save remote data that gvfs can
> access ...
>
> If you agree that should be changed, I can open a bug request to that ...
For security reasons, only the owner can read the .gvfs directory, so the
bacula-fd gets ERR=Permission denied when it runs as root.
It is difficult to avoid these errors because Bacula has to stat the file
before it can decide that it is in a different filesystem (or even exclude it
from the backup via the fileset definition).
__Martin

Hi there,
With the onefs = no shouldn't gvfs mounting point considered as external filesystem.
I got this warning on workstation or server when user's have let their X gnome session open and perharps use one gvfs ressource
open ( nautilus smb://server/share for example )
23-Dec 22:00 totem-fd JobId 107: Could not stat "/home/scan/.gvfs": ERR=Permission denied
Hopefully bacula-fd ( running as root can't access this folder ) otherwise, it will be able to save remote data that gvfs can
access ...
If you agree that should be changed, I can open a bug request to that ...
--
Bruno Friedmann (irc:tigerfoot)
Ioda-Net Sàrl http://www.ioda-net.ch
openSUSE Member
User http://www.ioda.net/r/osu
Blog http://www.ioda.net/r/blog
fsfe fellowship http://www.fsfe.org
GPG KEY : D5C9B751C4653227
vcard : http://it.ioda-net.ch/ioda-net.vcf

On 12/17/2010 02:07 PM, Frederik Himpe wrote:
> On one of my systems bacula-fd seems to have a memory leak. For example,
> now after a month bacula-fd takes up more than 280 MB of memory usage:
>
> root 1598 0.9 28.0 878856 288336 ? Ssl Nov17 415:04 /usr/sbin/bacula-fd -c /etc/bacula/bacula-fd.conf
>
> Right after starting bacula-fd, it only uses a few megabytes.
>
> On another system, bacula-fd is only taking up 45 MB of RSS memory and
> on a system with even less files to back-up, it uses a mere 5 MB of
> memory even after two months of uptime.
>
> Is this a known problem or is there a way to debug why memory usages
> continues to grow?
>
> I'm using bacula-fd-5.0.2-2.1 as provided by Debian Squeeze on AMD64.
>
Did this particular fd are connected to jobs with Accurate on in the fileset it used ?
If yes, check the doc about accurate, as it need more memory in the -fd
--
Bruno Friedmann (irc:tigerfoot)
Ioda-Net Sàrl http://www.ioda-net.ch
openSUSE Member
User http://www.ioda.net/r/osu
Blog http://www.ioda.net/r/blog
fsfe fellowship http://www.fsfe.org
GPG KEY : D5C9B751C4653227
vcard : http://it.ioda-net.ch/ioda-net.vcf

On one of my systems bacula-fd seems to have a memory leak. For example,
now after a month bacula-fd takes up more than 280 MB of memory usage:
root 1598 0.9 28.0 878856 288336 ? Ssl Nov17 415:04 /usr/sbin/bacula-fd -c /etc/bacula/bacula-fd.conf
Right after starting bacula-fd, it only uses a few megabytes.
On another system, bacula-fd is only taking up 45 MB of RSS memory and
on a system with even less files to back-up, it uses a mere 5 MB of
memory even after two months of uptime.
Is this a known problem or is there a way to debug why memory usages
continues to grow?
I'm using bacula-fd-5.0.2-2.1 as provided by Debian Squeeze on AMD64.
--
Frederik Himpe <fhimpe@...>
Vrije Universiteit Brussel