PeterB

Community Developer
  • Posts

    2729
  • Joined

  • Last visited

1 Follower

About PeterB

  • Birthday 12/16/1953

Converted

  • Gender
    Male
  • Location
    Tagum City, Philippines

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

PeterB's Achievements

Proficient

Proficient (10/14)

25

Reputation

  1. Strange that this is the first time I've seen it! Version 2021.09.24 running.
  2. What causes this? Message sent by email: Subject: cron for user root /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >dev/null 2>&1 /bin/sh: line 1: dev/null: No such file or directory Should that be '/dev/null'?
  3. Thanks for that. However, it seems that I don't have permission to access that topic. This confirms my view that plugin documentation is a real mess, with snippets of information scattered all around!
  4. Since I posted here a couple of weeks ago, I have been attempting to resurrect one of my old plugins, originally created about ten years ago. At that time, I copied an example and customised to create my .plg file. One of the elements in the .plg is an inline .page file. At that time, clicking on the 'Apply' button would invoke an rc.d/rc.<app> script. I find, now, that the rc.d file is no longer run from the web gui (it runs fine when invoked from the console). Ten years ago, "runCmd" in the submit for the 'Apply' button magically took the content of "cmd" and used that to invoke the rc.d script. I would be extremely grateful if anyone can assist me to get that working again, or can offer a simple example .page which I can copy. I attach my .page file. mpop.page
  5. Not according to the validators I've tried, and something has changed since reverting to 6.10.3 makes the problem go away!
  6. Thanks for the responses. I've put my .plg through two xml validators (w3schools & xmlvalidation.com) both of which report that the file has no errors. Can anyone recommend a validator which will identify the problem? What are these pre_plugin_checks and post_plugin_checks? These lines after the post_plugin_checks, in particular, suggest, to me, that the file (or whatever is being checked) is empty: sh: -c: line 1: unexpected EOF while looking for matching `'' sh: -c: line 2: syntax error: unexpected end of file
  7. I have a couple of plugins which I created years ago, to run dovecot and mpop on my unRAID server. I say 'years ago' - the dates on the files are from 2012 - 2014! If I remember correctly that was when unRAID went to 64 bit! They have been running without change and without problem for eight years. Last night I upgraded to unRAID 6.11 and those two plugins no longer startup. The output is as follows: I have reverted to unRAID 6.10.3 and the plugins run again. Other plugins I have created still run in 6.11 What has changed in 6.11 and what do I need to do to make my plugins fully compatible? Documentation on the plugin system is still seriously lacking!
  8. Undoubtedly good advice. However, I'm intrigued that two of us should encounter the same (or similar) issue, in the same week with, presumably, two different docker containers implementing the same application.
  9. I've just encountered this problem - CUPS is filling the docker image file with lots of temporary files. I deleted all these temporary files and the docker image file immediately returned to normal usage. My CUPS docker is from gfjardim's repository, but is identified as 'beta'. However, the files are created at around one every two seconds, each file is 38993 bytes and contains a list of *Font lines, eg: *Font Oklahoma-Oblique: Standard "(001.005)" Standard ROM *Font Oklahoma-BoldOblique: Standard "(001.005)" Standard ROM *Font Utah: Standard "(001.005)" Standard ROM *Font Utah-Bold: Standard "(001.005)" Standard ROM *Font Utah-Oblique: Standard "(001.005)" Standard ROM *Font Utah-BoldOblique: Standard "(001.005)" Standard ROM *Font UtahCondensed: Standard "(001.005)" Standard ROM *Font UtahCondensed-Bold: Standard "(001.005)" Standard ROM *Font UtahCondensed-Oblique: Standard "(001.004)" Standard ROM *Font UtahCondensed-BoldOblique: Standard "(001.005)" Standard ROM *Font BermudaScript: Standard "(001.005)" Standard ROM *Font Germany: Standard "(001.005)" Standard ROM *Font SanDiego: Standard "(001.005)" Standard ROM *Font US-Roman: Standard "(001.005)" Standard ROM The docker container was created 9 months ago but I cannot believe it has been creating these files for 9 months. Does anyone have any idea how to stop these files being created? The following processes run repeatedly: root 10559 25 0 18:03 ? 00:00:00 /bin/bash ./run root 10564 10559 0 18:03 ? 00:00:00 /bin/bash ./run root 10565 10564 9 18:03 ? 00:00:00 python -u /usr/local/bin/cloudprint -a /config/cloudpri root 10568 31 0 18:03 ? 00:00:00 sleep 1
  10. Some time ago, I reported a problem where DelugeVPN fails to reconnect following extended Internet connection outage. Yesterday, due to a strong typhoon , we suffered an Internet outage lasting more than 24 hours, plus a short power outage. When the Internet connection returned, as I expected, DelugeVPN failed to start. Before restarting manually, I remembered to capture the container's log. It was rather short: I'm not sure whether this directly relates to the failure to reconnect following Internet outage, without rebooting, but this is clearly what happens if the container starts and the Internet connection is not working. This logged activity was at 08:03 - I captured that log more than ten hours later and there had been no further activity from the container. The Internet connection had been live for more than three hours by that time. Hope this helps.
  11. The minidlna daemon doesn't appear to be crashing - it still has process id 80 and has consumed 34 seconds of cpu time, and no indication in the log from the container.
  12. I've just noticed multiple occurrences of this message appearing in my system log: Nov 8 21:35:58 Tower kernel: minidlnad[9980]: segfault at 20 ip 0000559ed8d47167 sp 00007ffd969bc770 error 4 in minidlnad[559ed8d1d000+2b000] Does this indicate an issue withing this container, or is the message coming from somewhere else?
  13. I went back to address this issue when I had more time available. The cause of my issue is that the default /etc/group which is provided by unRAID v6.10 now includes dovecot and dovenull groups, hence my attempt to create these groups in my install script was failing. My solution, for the time being, is to delete these two groups within my install script, before I create my own. This does beg the question, though - are we about to see dovecot provided as an integral (or even optional) service within unRAID. If not, why have these groups suddenly appeared in the group file?
  14. I have an old plugin which I created years ago, to run the dovecot mail server. It still runs perfectly well under v6.9.2. When I just updated to 6.10.0-rc2, I found that dovecot was failing to start. The system log shows that the plugin install script is executed, then the next line shows "retval: 6". I'm not sure whether this retval relates to the installation script or to something which happens after the script runs. The install script is: <!-- Here is the plugin installation script. This script is run every time upon system start-up and/or when the plugin is installed. --> <FILE Name="/tmp/dovecot-install" Run="/bin/bash"> <INLINE> <![CDATA[ # include our config vars source /boot/config/plugins/dovecot/dovecot.cfg # if dovecot doesn't exist, extract the tarball if [ ! -e "/usr/local/sbin/dovecot" ]; then ( cd /usr/local ; tar -xf /boot/config/plugins/dovecot/dovecot-2.2.13-x86_64-1pb.tgz ; # chmod 755 /usr/local/var/run/dovecot/empty # chmod 755 /usr/local/var/run/dovecot/login ) fi # # Add the next two lines for unRAID 6.9.0 groupadd -g 500 dovenull useradd -M -u 500 -g 500 -s /bin/false -d / -c 'Dovecot null user' dovenull groupadd -g 501 dovecot useradd -M -u 501 -g 501 -s /bin/false -d / -c 'User for Dovecot Mail Server' dovecot ]]> Is anyone able to identify why the plugin doesn't start or, at least, what "retval: 6" signifies? Oh, I was also caught out when I found that the installplg command no longer appears to be present! I guess that this now has to be done through the web interface.
  15. Okay, so I've just downloaded/installed 6.10.0-rc2. Indeed, all my nfs shares now are automounted with NFSv4. One little problem - all my NFS shares appear on my Linux Mint machine as protected. I'm told that I'm not the owner and cannot write to the share. My shares are all set as public and I used to be able to write to them under 6.9.2/NFSv3. Why the difference in behaviour and how do I resolve this? UPDATE: Okay, false alarm (I think). I rebooted my Mint desktop machine and all appears to be okay now. Although the files are shown as protected, I can still write/delete.