Consistent CTD on Deb Squeeze

[tcm 2]

greets.

emby fresh debian 9 install (and reinstall)

libraries for epub, video and audio via NAS SMB

consistent crash withiin moments requiring service emby-server restart.

two most recent log files attached.

 

assistance greatly appreciated, tnx!

~tcm

server-63652982530.txt

server-63652982708.txt

[dcrdev 251]

There doesn't look to be anything in those logs that are particularly telling - it just cuts out as oppose to crashing.

 

Can you attached the output of: 

systemctl status emby-server -l
journalctl | grep emby

Couple of initial thoughts:

• Is the partition on which /var/lib/emby on full?
• Are you running out of memory and do you have swap?

[tcm 2]

tnx for the quick response...

 

so i figured the what, just not the why.  by removing the NAS library sources and redirecting them to locally mounted dirs (of the same SMB shares) the issue seems to be resolved and I have been up and functional for the last 30 or so...

however, the shares are 755 and ro access shouldnt be an issue, so the why eludes me for now.  i'm not asking emby to save any data to those dirs, so this is functional, but messy.

 

i've generated the requested output, a slightly redacted version of the systemctl call is this:

● emby-server.service - Emby Server is a personal media server with apps on just about every device.
   Loaded: loaded (/usr/lib/systemd/system/emby-server.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2018-01-31 08:35:18 EST; 49min ago
 Main PID: 6786 (EmbyServer)
    Tasks: 28 (limit: 4915)
   CGroup: /system.slice/emby-server.service
           ├─ 589 /opt/emby-server/bin/ffprobe -i file:/home/redacted_user/Vault/Media/Audio/Music/redacted_track.mp3 -threads 0 -v info -print_format json -show_streams -show_format
           └─6786 /opt/emby-server/system/EmbyServer -programdata /var/lib/emby -ffmpeg /opt/emby-server/bin/ffmpeg -ffprobe /opt/emby-server/bin/ffprobe -restartexitcode 3 -updatepackage emby-server-deb_{version}_amd64.deb

Jan 31 09:24:08 hostname emby-server[6786]:   libavfilter     6.107.100 /  6.107.100
Jan 31 09:24:08 hostname emby-server[6786]:   libswscale      4.  8.100 /  4.  8.100
Jan 31 09:24:08 hostname emby-server[6786]:   libswresample   2.  9.100 /  2.  9.100
Jan 31 09:24:08 hostname emby-server[6786]:   libpostproc    54.  7.100 / 54.  7.100
Jan 31 09:24:08 hostname emby-server[6786]: Input #0, mp3, from 'file:/home/redacted_user/Vault/Media/Audio/Music/redacted_artist_01/redacted_album_01/redacted_track_01.mp3':
Jan 31 09:24:08 hostname emby-server[6786]:   Metadata:
Jan 31 09:24:08 hostname emby-server[6786]:     title           : redacted_title
Jan 31 09:24:08 hostname emby-server[6786]:     artist          : redacted_artist
Jan 31 09:24:08 hostname emby-server[6786]:     track           : 05
Jan 31 09:24:08 hostname emby-server[6786]:     album           : redacted_album 

and I can certainly upload the journal, however as it is apparently a wander through my library, it is large.  might make for a fun read on what i think is worth keeping around, I suppose.  Let me know if you still want me to upload it.

 

so, ive got the workaround, still curious on resolution.

tnx again for the interest.

peace.

~t

Edited January 31, 2018 by tcm

[dcrdev 251]

I would expect to see denial messages in the log, if it were a permission issue; odd.

 

That being said something pops out at me, which is the mount point for your share resides in a home directory. I have seen several users do this, usually it's because they are relying on a desktop environment to do the mounting. Directories under /home have acls that prevent other users accessing them even if the standard posix permissions say otherwise.

 

I would advise you to create a permanent mount point in /etc/fstab for somewhere other than /home i.e. /mnt/myshare or /myshare.

[tcm 2]

interesting.  so, the original library sources which seemed to break emby were smb share locations; \\ip_address\share

 

i hadnt thought of intrinsic problems of keeping the mount in the home dir, things seem to be stable now, but ill investigate.

thanks for that, although I am deeply hurt by your insinuations.  

 

Rely on a desktop environment for mounting, indeed.

 

  

 

tnx again!

~t

Edited February 1, 2018 by tcm