Linux - DesktopThis forum is for the discussion of all Linux Software used in a desktop context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Probably pulse is not started or something like that. Run mplayer with one or several -v's for more information or master -msglevel option if you want to see only relevant messages.
The non-interactive process can't find the pulseaudio socket. It is in directory $XDG_RUNTIME_DIR/pulse, but XDG_RUNTIME_DIR is probably not defined in the non-interactive procmail process. Check what the value of $XDG_RUNTIME_DIR is in your interactive session and set it to the same value in front of your mplayer command.
The non-interactive process can't find the pulseaudio socket. It is in directory $XDG_RUNTIME_DIR/pulse, but XDG_RUNTIME_DIR is probably not defined in the non-interactive procmail process. Check what the value of $XDG_RUNTIME_DIR is in your interactive session and set it to the same value in front of your mplayer command.
Setting XDG_RUNTIME_DIR to run/user/101 worked! Will XDG_RUNTIME_DIR always be this value? Does it change on reboots?
Setting XDG_RUNTIME_DIR to run/user/101 worked! Will XDG_RUNTIME_DIR always be this value? Does it change on reboots?
It does not change on reboots. 101 is your UID.
But the directory is created when your session starts (you log in). And it's removed when the session ends. So, immediately after reboot the directory does not exist. Your mail sounds will probably work only while you are logged in.
Last edited by Petri Kaukasoina; 01-25-2024 at 01:39 AM.
But the directory is created when your session starts (you log in). And it's removed when the session ends. So, immediately after reboot the directory does not exist. Your mail sounds will probably work only while you are logged in.
Well, that's not going to work. The procmailrc script looks for certain email subjects that refer to computer problems, systems down, attempted break-ins, etc. and run a script that sounds an audible alarm. It needs to be able to work without anyone being logged in. This used to work find with Slackware 14.2, kernel 4.4.301.
I had a similar problem. I use vnc remotely to access an fvwm screen started at my work computer and there is no session logged in then. So, no /run/user/$UID, because it was deleted when I logged out. I can't remember what the problem was that the missing $XDG_RUNTIME_DIR caused but I solved it by adding these lines in the beginning of ~/.bashrc
/dev/shm is similar to /run/user/$UID, it's tmpfs in RAM, removed in reboot. My .bashrc creates the work directory in it the first time I log in after reboot and it is not removed until the next reboot. You could even mkdir it in /etc/rc.d/rc.local if you need it before logging in the first time.
(I haven't tried it with something like kde or xfce, so YMMV.)
Last edited by Petri Kaukasoina; 01-25-2024 at 11:09 AM.
I had a similar problem. I use vnc remotely to access an fvwm screen started at my work computer and there is no session logged in then. So, no /run/user/$UID, because it was deleted when I logged out. I can't remember what the problem was that the missing $XDG_RUNTIME_DIR caused but I solved it by adding these lines in the beginning of ~/.bashrc
/dev/shm is similar to /run/user/$UID, it's tmpfs in RAM, removed in reboot. My .bashrc creates the work directory in it the first time I log in after reboot and it is not removed until the next reboot. You could even mkdir it in /etc/rc.d/rc.local if you need it before logging in the first time.
(I haven't tried it with something like kde or xfce, so YMMV.)
So, `whoami` is going to give the user's login id, e.g. "markf". You are therefore creating the directory /dev/shm/markf, and you are exporting that directory as XDG_RUNTIME_DIR.
So basically, XDG_RUNTIME_DIR is an arbitrary directory and could possibly be anthing at all, right? Even /tmp? Why would I need to create something in /dev/shm?
So basically, XDG_RUNTIME_DIR is an arbitrary directory and could possibly be anthing at all, right? Even /tmp? Why would I need to create something in /dev/shm?
Right. No need. I think that if you unset XDG_RUNTIME_DIR, /tmp will be used. It should not be a directory which more than one machine mounts. /dev/shm and /tmp are always local. I have just wanted to move everybody's stuff out of filling /tmp.
$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, ...) should be stored. The directory MUST be owned by the user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700.
The lifetime of the directory MUST be bound to the user being logged in. It MUST be created when the user first logs in and if the user fully logs out the directory MUST be removed. If the user logs in more than once he should get pointed to the same directory, and it is mandatory that the directory continues to exist from his first login to his last logout on the system, and not removed in between. Files in the directory MUST not survive reboot or a full logout/login cycle.
The directory MUST be on a local file system and not shared with any other system. The directory MUST by fully-featured by the standards of the operating system. More specifically, on Unix-like operating systems AF_UNIX sockets, symbolic links, hard links, proper permissions, file locking, sparse files, memory mapping, file change notifications, a reliable hard link count must be supported, and no restrictions on the file name character set should be imposed. Files in this directory MAY be subjected to periodic clean-up. To ensure that your files are not removed, they should have their access time timestamp modified at least once every 6 hours of monotonic time or the 'sticky' bit should be set on the file.
If $XDG_RUNTIME_DIR is not set applications should fall back to a replacement directory with similar capabilities and print a warning message. Applications should use this directory for communication and synchronization purposes and should not place larger files in it, since it might reside in runtime memory and cannot necessarily be swapped out to disk.
Really!? This was not needed on Slackware 14.2 (kernel 4.4.301). That procmailrc script worked fine without me beling logged in. This is just the latest in numerous posts I've made at LQ going back years trying to get sound to work on a variety of Linux releases, including via KDE. It has been a constant pain. Fortunately, the LQ experts have always helped me solve the issue. If I installed Windows on this same system I'd have no problem with sound. Why is Windows sound hands-off plug-and-play and Linux is not? (rhetorical)
Oh well, I'll try the suggested /dev/shm idea ASAP and report back.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
