I’m not shading you here, I just think You’re kind of missing the point of where samba itself comes into play as far as inhibiting sleep goes. There a myriad different ways you can be copying files where Samba wouldn’t even know as a client.
Are you using network mounts? Well then you’re operating in Fuse most likely.
Are you using a GUI file manager under Gnome? Could be gvfs, could be fuse, a combo, or a direct call to SMB libs, who knows. No Samba proc calls though.
Are you copying using smbclient directly from a cli? Well maybe then samba as a construct would know about it and be able to do something.
Point is, it’s not really Samba’s problem. It is solely a cohesive collection of things that group together to act as a Windows compatible file server and domain controller.
Try looking at Caffeine or the KDE equivalent depending on what you’re running. Maybe even consider not using SMB at all if it’s that big of an issue. Or maybe network mounts and rsync would work better for you. Literally thousands of workarounds and possibilities to solve your particular problem.
For sure, I don’t know the internals of Samba, but surely the server knows that it’s serving a file no matter how the client accesses it. I don’t think a few dbus messages would cause issues.
I have my own service that looks at the network traffic via /proc and a few other things. That sends the system to sleep itself if everything looks truly idle.
I do think it would be nice for a file server like samba to inhibit sleep using the standard interface for it. But yeah, I appreciate there are complications, like video playback is presumably pulling a small extent of a file at a time, so there would have to be some kind of timer before releasing the inhibition or the system would sleep between transfers.
EDIT: I just took a look; with loglevel set to 3 for smb and smb2 I see log messages like:
These occur at most 10 seconds apart when playing a video over a share from another host. I don’t see why the smbd daemon couldn’t inhibit sleep untill smbd_smb2_read hasn’t run for a minute or so. You could have a script that monitors that log output and does this externally but it’d be nice to have built in.
The server side should never be expected to sleep at all, so that’s just a totally different thing. I was under the impression you were having issues with the client. If you have sleep enabled on the server/service side of things and you expect it to work, then there’s yer problem. You’ll need some custom work to prevent your power profiles and such from overriding systemd-sleep or whatever you intend to happen.
Ah, that’s the misunderstanding. The original comment was talking about “watching something on another pc”. Like playing a video from a desktop PC on a laptop in another room. So it’s the samba server we want to prevent from sleeping, not the client. Yes it’d be nice to have a 24/7 media server set up, but for the simple case of sharing a file from one PC to another, it’d be nice for the server not to sleep in the middle of it by default.
I’m not shading you here, I just think You’re kind of missing the point of where samba itself comes into play as far as inhibiting sleep goes. There a myriad different ways you can be copying files where Samba wouldn’t even know as a client.
Are you using network mounts? Well then you’re operating in Fuse most likely.
Are you using a GUI file manager under Gnome? Could be gvfs, could be fuse, a combo, or a direct call to SMB libs, who knows. No Samba proc calls though.
Are you copying using smbclient directly from a cli? Well maybe then samba as a construct would know about it and be able to do something.
Point is, it’s not really Samba’s problem. It is solely a cohesive collection of things that group together to act as a Windows compatible file server and domain controller.
Try looking at Caffeine or the KDE equivalent depending on what you’re running. Maybe even consider not using SMB at all if it’s that big of an issue. Or maybe network mounts and rsync would work better for you. Literally thousands of workarounds and possibilities to solve your particular problem.
For sure, I don’t know the internals of Samba, but surely the server knows that it’s serving a file no matter how the client accesses it. I don’t think a few dbus messages would cause issues.
I have my own service that looks at the network traffic via /proc and a few other things. That sends the system to sleep itself if everything looks truly idle.
I do think it would be nice for a file server like samba to inhibit sleep using the standard interface for it. But yeah, I appreciate there are complications, like video playback is presumably pulling a small extent of a file at a time, so there would have to be some kind of timer before releasing the inhibition or the system would sleep between transfers.
EDIT: I just took a look; with loglevel set to 3 for smb and smb2 I see log messages like:
smbd_smb2_read: fnum 1712966762, file my_video.mkv, length=262144 offset=82366464 read=262144These occur at most 10 seconds apart when playing a video over a share from another host. I don’t see why the smbd daemon couldn’t inhibit sleep untill smbd_smb2_read hasn’t run for a minute or so. You could have a script that monitors that log output and does this externally but it’d be nice to have built in.
The server side should never be expected to sleep at all, so that’s just a totally different thing. I was under the impression you were having issues with the client. If you have sleep enabled on the server/service side of things and you expect it to work, then there’s yer problem. You’ll need some custom work to prevent your power profiles and such from overriding systemd-sleep or whatever you intend to happen.
Ah, that’s the misunderstanding. The original comment was talking about “watching something on another pc”. Like playing a video from a desktop PC on a laptop in another room. So it’s the samba server we want to prevent from sleeping, not the client. Yes it’d be nice to have a 24/7 media server set up, but for the simple case of sharing a file from one PC to another, it’d be nice for the server not to sleep in the middle of it by default.