The officially official Devuan Forum!

You are not logged in.

#1 Re: Other Issues » ATK bridge not found [SOLVED] » 2018-01-12 14:22:42

libatk-adaptor had not been installed, so I have now installed it. When I ran gksu there was no error message, although there was not always an error message, so it will take some time to verify that it has really fixed it.

Thank you for the suggestion.


#2 Re: Other Issues » ATK bridge not found [SOLVED] » 2018-01-11 17:18:51

I see that libgksu2-0 depends on libatk1.0-0


#3 Re: Other Issues » ATK bridge not found [SOLVED] » 2018-01-11 16:54:34

I get an error message too. When I run gksu 'rxvt -rv' I get the message :-

Gtk-Message: Failed to load module "atk-bridge"
Gkr-Message: secret service operation failed: The name org.freedesktop.secrets was not provided by any .service files
Gkr-Message: secret service operation failed: The name org.freedesktop.secrets was not provided by any .service files
Gkr-Message: secret service operation failed: The name org.freedesktop.secrets was not provided by any .service files

The command does run and the processes which run are :-

xxxxxx    2862  0.3  0.2 172624 20548 pts/0    S    16:44   0:00                  |   |       \_ gksu rxvt -rv
root      2869  0.0  0.0  46864  2672 pts/1    Ss+  16:44   0:00                  |   |           \_ /bin/su root -c /usr/lib/libgksu/gksu-run-helper "rxvt -rv"
root      2871  0.0  0.0  12004  1088 ?        Ss   16:44   0:00                  |   |               \_ /usr/lib/libgksu/gksu-run-helper rxvt -rv
root      2875  0.0  0.0   4292   756 ?        S    16:44   0:00                  |   |                   \_ sh -c rxvt -rv
root      2876  0.0  0.1 107008 13616 ?        S    16:44   0:00                  |   |                       \_ rxvt -rv
root      2877  0.0  0.0  94932  4408 ?        S    16:44   0:00                  |   |                           \_ rxvt -rv
root      2879  0.0  0.0  19992  3752 pts/2    Ss+  16:44   0:00                  |   |                           \_ bash

Is it something to do with gksu-run-helper?


#4 Re: Desktop and Multimedia » [Solved] Firefox 52.5.2 (64-bit) ESR crashes on drag/drop intent » 2018-01-08 14:43:07

Altoid wrote:
fungus wrote:

... only has Palemoon which is my preferred browser for some time now.

Looks nice but I cannot use my preferred add-ons: UBlockOrigin, Privacy Badger, etc.

Palemoon works nicely with uBlockOrigin, as well as NoScript, as fungus mentions.


#5 Re: Installation » [SOLVED] startx fails since upgrade to 4.9 kernel » 2018-01-06 16:06:48

Looking at kernels on Jessie, you have available linux-image-4.9.0-0.bpo.4-amd64 and linux-image-4.9.0-0.bpo.2-amd64.
These version numbers are the package numbers which are a bit different from the kernel versions.
The bpo.4 package is kernel 4.9.65-3+deb9u1~.
It is kernel 4.9.65 which people are complaining about causing graphics difficulties.
The bpo.2 package is kernel 4.9.18-1~bpo8+1.
Some people have reported that going back to an earlier 4.9 kernel got round their graphics problems.
If it is easy for you to try this earlier version, it may show whether the kernel is the problem.


#6 Re: Installation » [SOLVED] startx fails since upgrade to 4.9 kernel » 2018-01-05 19:04:58

Whoops! 4.13 is in backports in ascii and I just noticed that you are running Jessie. Sorry.


#7 Re: Installation » [SOLVED] startx fails since upgrade to 4.9 kernel » 2018-01-05 15:55:23

There have been a number of graphics problems reported with 4.9. I hit one with Intel graphics, but there were others.

There were suggestions that it was fixed by installing 4.13 from backports. This installs ok and I have not had any problems yet, but have not given it a good thrashing.


#8 Re: Installation » [CLOSED] <Ascii> Minimal Install - OB - Issues » 2018-01-03 14:34:07

fungus wrote:

Someone is working on runit it seems.

I didn't have to do anything to make runit work as a processor supervisor, it just works in both jessie and ascii. The fun bit is configuring it to run stuff ;-)
You can run it alongside SysV init and I think I saw that you can use it with OpenRC in a similar fashion, if you want your daemons supervised, i.e. restarted if they fail.


#9 Re: DIY » runit as a process supervisor » 2018-01-03 14:23:20


Another interesting example is Apache. It seems that the way to start it is with "apache2ctl start" as that is the way to get the environment set-up correctly. This results in the daemon(s) running in the background. The "run" file should wait for the daemon(s) to stop. As apache produces a pid file, it is easy to find the top daemon. What we would like to do is "wait $PID". Unfortunately this does not work as $PID is not a child of mine! It is, however, possible to look at /proc/$PID :- … -to-finish

while [[ ( -d /proc/$PID ) && ( -z `grep zombie /proc/$PID/status` ) ]]; do
    sleep 1

Although I got a syntactical error with this, so I ended up with this "run" file :-

#!/bin/sh -eu
exec 2>&1
echo "executing /etc/sv/apache2/run"

/usr/sbin/apache2ctl configtest
/usr/sbin/apache2ctl start

# allow time for the PID file to be written

until [ -s /var/run/apache2/ ]
   if [ $n -gt 5 ]
      echo "/var/run/apache2/ not found after ${n}s.
      exit 1
   n=$(( $n + 1 ))
   sleep 1

read PID < /var/run/apache2/
echo "apache2 running as pid ${PID}."

# wait for the $PID to stop

while [ -d /proc/$PID ] && [ -z `grep zombie /proc/$PID/status` ]
    sleep 60

I also set up a "finish" file as stopping the "run" script would not stop apache.

# exec 2&>1
echo "calling /etc/sv/apache2/finish"
/usr/sbin/apache2ctl stop

I had wondered whether I could use chpst to put a lock on /proc/$PID or one of the files in that directory and then have a second copy of chpst to wait to get a lock on that file, to avoid the looping, but I though that it was best to avoid playing with the procfs!

I wonder whether one should take a different course of action if the $PID becomes a zombie?


#10 Re: DIY » runit as a process supervisor » 2017-12-30 16:15:19

Postfix again

I was reviewing the setup for Postfix, and having a fiddle, when I discovered that I had misunderstood the flags to the "master" program. Under SysV init, master runs with "-w", which launches it as a daemon, but does not return until the daemon is running correctly. If you omit the "-w" flag then master runs in the foreground, which is what we want! The set up then becomes very simple. All that is needed is a simple run file and you may setup logging if you wish. The "echo" in the run file is reported through the logging mechanism.

cat << EOF > run
#!/bin/sh -eu
echo "executing /etc/sv/postfix/run"
/usr/sbin/postfix check
exec /usr/lib/postfix/master

The "-eu" flags cause the script to fail on any unchecked errors. There is no need for a finish script. "ps uaxf" then reports :-

root      2658  0.0  0.0   4100   688 ?        Ss   14:31   0:00  \_ runsv postfix
log       2662  0.0  0.0   4244  1240 ?        S    14:31   0:00      \_ svlogd -tt /var/svlogd/postfix
root      3697  0.0  0.0  36168  3820 ?        Ss   15:54   0:00      \_ /usr/lib/postfix/master
postfix   3810  0.0  0.0  38232  3724 ?        S    15:54   0:00          \_ pickup -l -t unix -u -c
postfix   3811  0.0  0.0  38280  3924 ?        S    15:54   0:00          \_ qmgr -l -t unix -u


#11 Re: Off-topic » The Joke Thread » 2017-12-28 09:38:11

What's the difference between a buffalo and a bison?

You can't wash your hands in a buffalo.

#12 Re: Desktop and Multimedia » Screen goes mad - ascii » 2017-12-24 17:27:09

Running "apt-cache search linux-image" shows the range of kernels available, which includes linux-image-4.13.0-0.bpo.1-amd64.
I was able to select this in Synaptic and it did not want to pull in anything else. It installed with no problem and it leaves a couple of older kernels (4.9.0-3 and 4.9.0-4) which can also be booted up. The new kernel boots up with no problem. It is too early to tell if it fixes the graphics problem, but it is no worse!


#13 Re: Desktop and Multimedia » Screen goes mad - ascii » 2017-12-24 16:40:46

I have had a look at Debian bugs and there seem to be several reports of problems with the graphics.
People seem to find that the problem is the result of upgrading from kernel 4.9.0-3 to 4.9.0-4.

A few of the bug reports are :-

Some of the later reports suggest that the problem may be fixed in kernel 4.13 from backports. … bug=884638

I'm currently on the wrong machine, so will have to go to my ascii machine to investigate.


#14 Re: Desktop and Multimedia » Screen goes mad - ascii » 2017-12-22 15:39:00

The problem with trying to change the acceleration method is really that it is a work-around that doesn't actually work, in that it stops X from starting normally. The fix for that is to not do it ;-)

The real problem is with an instability with the graphics.

On both occasions when I have triggered it, I typed a <return> which led to a chunk of text moving vertically, which triggered the instability. In one case in emacs the chunk of text was moved down and in the other typing <return> to man, caused the chunk of text to move up.

I can imagine that the graphics driver does an optimisation and tells the graphics card to move an area of the display, rather than re-drawing it. The Arch forum article mentioned changing the acceleration method. I was looking at Xorg.0.log, to see what acceleration was being used and saw that it mentions

glamor: OpenGL accelerated driver based

This problem has ony occured in the last few days, so it may have been
introduced in a recent upgrade. The kernel was updated on 17 Dec 2017

Preparing to unpack .../26-linux-image-4.9.0-4-amd64_4.9.65-3_amd64.deb ...
Unpacking linux-image-4.9.0-4-amd64 (4.9.65-3) over (4.9.51-1) ...

Grub is also offering 4.9.0-3-amd64, so I could boot that. It seems to date back to 19th Sept. What is the most helpful thing to do to track down this odd behaviour?


#15 Re: Desktop and Multimedia » Screen goes mad - ascii » 2017-12-21 16:57:11

I have been running ascii since 2015 on my Zenbook, as far as I can tell! and I have only had the screen problem once and that was a couple of days ago.

The advice on the Arch wiki is from 2015, so a bit old. When I put the above file in place, to set the AccelMethod to "uxa" and reboot, at the expected time it switches to tty7, but a couple of system messages flash up, but no X. If I typed <ctl><alt><f1> it switches to tty1 with the login prompt, but after a few seconds a couple of system messages flash up, making it difficult to log in. Typing <ctl><alt><f1> again would get me to the login prompt, but it proved too hard for me to actually log in. The other ttys, from tty1 to tty6 all behaved similarly. I had to break in with the power switch and log in in recovery mode and move the config file out of the way and then it would boot up ok.

Xorg.0.log mentions :-

[    11.770] xorg-server 2:1.19.2-1+deb9u2 ( 
[    11.799] (II) Loading sub module "glamoregl"
[    11.799] (II) LoadModule: "glamoregl"
[    11.800] (II) Loading /usr/lib/xorg/modules/
[    11.811] (II) Module glamoregl: vendor="X.Org Foundation"
[    11.811] 	compiled for 1.19.2, module version = 1.0.0
[    11.811] 	ABI class: X.Org ANSI C Emulation, version 0.4
[    11.811] (II) glamor: OpenGL accelerated driver based.
[    11.847] (II) glamor: EGL version 1.4 (DRI2):
[    11.859] (II) modeset(0): glamor initialized

Then as I was editing in emacs, I pressed <enter>, which moved about 10 lines down and the screen started to flicker again, but then recovered. dmesg again reports, at about the right time :-

[ 3238.966087] [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

I am not able to reproduce this reliably.


#16 Re: Desktop and Multimedia » Screen goes mad - ascii » 2017-12-20 19:03:46

Thank you for that. I can confirm that it does find the file in either /usr/share/X11/xorg.conf.d/ or /etc/X11/xorg.conf.d/. The advice about overwrites on upgrades is well made.

The bad news, however, is that the file stops X from coming up, so I had to move it out of the way. I have not yet had a chance to track down the problem yet.


#17 Desktop and Multimedia » Screen goes mad - ascii » 2017-12-20 15:07:45

Geoff 42
Replies: 8

I was using my ascii laptop when the screen suddenly went mad!

I think I had open :- rxvt, palemoon, emacs & claws. I was looking at a man page in the rxvt window and had pressed the space bar a few times to get to the right place and then pressed return and the whole screen went mad. The windows appeared to be moving rapidly, possibly sideways. If I left it, it would eventually stop, but when I moved the mouse it started again. However, I was able to close a couple of windows, which I think may have been emacs and palemoon. After that the screen went back to normal and I was able to carry on.

I found the following information in syslog and dmesg :-

Dec 19 16:37:34 gold kernel: [ 5678.028125] [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

My laptop is an Asus Zenbook UX305 running ascii & lxde.

I duck-duck-went and found the following on the Arch forum :-

where they suggest changing the acceleration method back to UXA instead of SNA, with a file called 20-intel.conf

Section "Device"
    Identifier  "Intel Graphics"
    Driver      "intel"
    Option      "AccelMethod"  "uxa"
    #Option      "AccelMethod"  "sna"

and putting it in /etc/X11/xorg.conf.d/. I do not have this directory but have found /usr/share/X11/xorg.conf.d
and have therefore put it there. Is this the right location?


#18 Re: DIY » runit as a process supervisor » 2017-12-17 15:34:17

Package upgrades

I was wondering about package upgrades as it appears that many services are automatically stopped before an upgrade and restarted afterwards, or possibly simply restarted after the upgrade. To have a look at how this worked I had a look through a ".deb" file. I copied one over to somewhere safe :-

cp /var/cache/apt/archives/apache2_2.4.10-10+deb8u11_amd64.deb .

and then had a look with spacefm/Xarchiver, extracting the control.tar file into my safe area. In the "postinst" file near the end is the code fragment :-

# Automatically added by dh_installinit
if [ -x "/etc/init.d/apache2" ]; then
	update-rc.d apache2 defaults 91 09 >/dev/null
	if [ -n "$2" ]; then
	invoke-rc.d apache2 $_dh_action || true

Indeed, prerm and postrm also use invoke-rc.d and update-rc.d to stop apache and then remove the init.d links.
Interestingly, only postrm makes reference to systemd.

I suspect that the quick workaround is to do an apt-get upgrade and stop it when it asks. You would then inspect the packages to be upgraded and if you spot any of the services you have under runit, you would stop them manually. Then you would actually do the upgrade and then you could restart the services! I'm not sure that is the best answer! Runit's "sv" program does understand init.d and can be linked to from /etc/init.d

So that might be a way to have your services handled safely, although I wonder whether any upgrades might want to overwrite the service's init.d script, which could lead to sv be overwritten!


#19 Re: DIY » runit as a process supervisor » 2017-12-16 16:04:30


The next service to try was postgresql. This proved to be a bit more complex, in that there was more to set up.
The command line according to the ps command was :-

/usr/lib/postgresql/9.4/bin/postgres -D /var/lib/postgresql/9.4/main -c config_file=/etc/postgresql/9.4/main/postgresql.conf

Logging was set up and then on putting this command into the run file it failed to run. The log file reported that postgres must not be run as root. "chpst" was then used to set the user and group to postgres:postgres. This then failed as it could not read the ssl certificate. "chpst" allows for a number of groups to be set so using postgres:postgres:ssl-cert seems to work, although postgres is already in the ssl-group in /etc/group! The next problem was that it needed the socket directory to be created in /var/run, which, as it is a tmpfs, disappears on a re-boot. It was also clear that the stats sub-directory also needed to be recreated. This can be done with install, to set up permissions and ownership in one command.

This then seems to work, but there are a number of directories involved and these may change with versions, indeed the version number is included in several of the directories. It therefore seemed reasonable to make these easy to configure. There is some documentation on clusters of databases, but I am only running one. It may be that the one database is called "main" by default and that that part of the path names should also be easy to configure.

The currently working set up is like this :-

mkdir /etc/sv/postgresql
cd /etc/sv/postgresql

cat << EOF > run
#!/bin/sh -eu
exec 2>&1




# create socket and stats directories

install -d -m 2775 -o postgres -g postgres ${RUNROOT} ${STATDIR}

exec chpst -u postgres:postgres:ssl-cert ${BINFILE} -D ${DATAFILE} -c config_file=${CONFFILE}

mkdir log
cat << EOF > log/run
exec chpst -ulog svlogd -tt /var/svlogd/postgresql

chmod a+x run log/run
mkdir /var/svlogd/postgresql
chown log /var/svlogd/postgresql

cd /etc/service
/etc/init.d/postgresql stop
update-rc.d postgresql disable
ln -s /etc/sv/postgresql .

tail -f /var/svlogd/postgresql/current

Once you are happy that the log file is not producing lots of errors you can ^C out of it!


#20 Re: DIY » runit as a process supervisor » 2017-12-11 10:46:12

Current state

across 2 machines, the following are running under runit :-


For most of them it is simply the case of setting up a run file containing the command along with the flag to stop it from running as a daemon, but remain attached to stdin/stdout. With a few (lxdm) it is rather the case that you leave out the flag that causes it to become a daemon. It is probably a good idea to set up logging for most of them. It is only slightly more complex when the program really does want to run as a daemon, such as postfix.

There is the question of why the SysV init scripts are so complex. I think that these have evolved this way as they check that everything has been set up correctly and where possible put things in place that should be there. It is understandable that a general purpose distribution will want everything to just work out of the box. The price of this is perhaps that the mechanism becomes more complex. One of the complexities seems to be the setting up of a PID file. I think that this is necessary so that init is able to control the service, whereas this is probably not necessary under runit.

The services which I have set up do seem to be simpler, but it may be that they do actually work because they were originally set up under SysV init, which sorted out any problems!

If you are developing a new service or have one which is not set up for SysV init, then it may be easier to get it running under runit.


#21 Re: News & Announcements » eudev is now in ascii » 2017-12-08 16:16:19

Yes, thank you. The net.ifnames=0 does work. It took me a little while as I had to work out how to separate entries in that line. It appears that a space is used. I therefore have :-

GRUB_CMDLINE_LINUX_DEFAULT="earlyprintk=vga,keep net.ifnames=0"


#22 Re: News & Announcements » eudev is now in ascii » 2017-12-08 15:04:46

With eudev installed I am getting my wifi appearing as wlan0, but my ethernet is coming up as enx followed by the mac address. I am not sure where this is set. dmesg reports (with the mac address obscured)

[    2.372782] r8152 2-2:1.0 eth0: v1.08.8
[    2.375118] r8152 2-2:1.0 enx2a2a2a2a2a2a: renamed from eth0


#23 Re: News & Announcements » eudev is now in ascii » 2017-12-08 14:35:16

I think that you need both eudev and libeudev1, this should then work.

# apt-get install eudev=3.2.2-9 libeudev1=3.2.2-9
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be DOWNGRADED:
  eudev libeudev1
0 upgraded, 0 newly installed, 2 downgraded, 0 to remove and 0 not upgraded.
Need to get 1,068 kB of archives.
After this operation, 15.4 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 ascii/main amd64 eudev amd64 3.2.2-9 [976 kB]
Get:2 ascii/main amd64 libeudev1 amd64 3.2.2-9 [92.3 kB]
Fetched 1,068 kB in 0s (1,730 kB/s)  
dpkg: warning: downgrading eudev from 3.2.2-devuan2.7 to 3.2.2-9
(Reading database ... 136018 files and directories currently installed.)
Preparing to unpack .../eudev_3.2.2-9_amd64.deb ...
Unpacking eudev (3.2.2-9) over (3.2.2-devuan2.7) ...
dpkg: warning: downgrading libeudev1:amd64 from 3.2.2-devuan2.7 to 3.2.2-9
Preparing to unpack .../libeudev1_3.2.2-9_amd64.deb ...
Unpacking libeudev1:amd64 (3.2.2-9) over (3.2.2-devuan2.7) ...
Setting up libeudev1:amd64 (3.2.2-9) ...
Setting up eudev (3.2.2-9) ...
Installing new version of config file /etc/init.d/eudev ...

  Warning: eudev will default to the older network
  interface names, such as eth0 or wlan0. If you use
  the new names, such as enp0s3, you will need to add
  the following to the boot command:

update-initramfs: deferring update (trigger activated)
Processing triggers for libc-bin (2.24-11+deb9u1) ...
Processing triggers for man-db ( ...
Processing triggers for initramfs-tools (0.130) ...
update-initramfs: Generating /boot/initrd.img-4.9.0-4-amd64


#24 Re: DIY » runit as a process supervisor » 2017-12-07 09:57:39

I spotted another method of hanging for a daemon (rpc.nfsd) that detaches (in the Gentoo info).
The README file for the rpc.nfsd "run" says :-

"rpc.nfsd is a "fake" service implemented using lock-wedging. Doing it this way allows sv stop rpc.nfsd to work, by stopping it in the finish script."

After it has started the daemon, which detaches, the run file then does this :-

exec chpst -L supervise/runlock chpst -l supervise/runlock true

The change process state program (chpst) uses the -L switch to open the file supervise/runlock for writing, and obtain an exclusive lock on it. It then runs another copy of chpst which similarly gets a lock on the same file and then runs and returns "true".
The difference is that -L will fail immediately if it cannot get the lock, while -l will wait until it can get the lock. This line will therefore hang until it gets "sv stop postfix", when it will terminate true so that "finish" will be executed, which is set up to actually stop postfix. This does work as described, once the control/t file was moved out of the way, which was by-passing killing off the "run" process. The normal shutdown proceedure continues as before.

The set up is now fairly simple as it is only necessary to set up "run" & "finish" along with the logging.

cd /etc/sv/postfix
cat << EOF > run
exec 2>&1
echo "executing /etc/sv/postfix/run"
/usr/sbin/postfix start
exec chpst -L supervise/runlock chpst -l supervise/runlock true

cat << EOF > finish
exec 2>&1
echo "calling /etc/sv/postfix/finish"
/usr/sbin/postfix stop

mkdir log
cat << EOF > log/run
exec chpst -ulog svlogd -tt /var/svlogd/postfix

chmod a+x run finish log/run

the part of the output of ps uaxf relating to the postfix daemon looks like this :-

root      2767  0.0  0.0   4100   696 ?        Ss   09:02   0:00  \_ runsv postfix
log       2768  0.0  0.0   4244   708 ?        S    09:02   0:00      \_ svlogd -tt /var/svlogd/postfix
root      2771  0.0  0.0   4104   652 ?        S    09:02   0:00      \_ chpst -l supervise/runlock true
root      2903  0.0  0.0  36168  3152 ?        Ss   09:02   0:00 /usr/lib/postfix/master -w
postfix   2904  0.0  0.0  38232  3884 ?        S    09:02   0:00  \_ pickup -l -t unix -u -c
postfix   2905  0.0  0.0  38280  3936 ?        S    09:02   0:00  \_ qmgr -l -t unix -u


#25 Re: DIY » runit as a process supervisor » 2017-12-04 15:13:32

The actual file set up in /etc/sv/postfix looks like this :-

# find /etc/sv/postfix/ -name '*' -ls
651625    4 drwxr-xr-x   5 root     root         4096 Dec  3 17:41 /etc/sv/postfix/
652292    4 -rwxr-xr-x   1 root     root           71 Nov 24 14:31 /etc/sv/postfix/finish
652288    4 -rwxr-xr-x   1 root     root          121 Dec  3 17:41 /etc/sv/postfix/run
656409    4 drwxr-xr-x   2 root     root         4096 Dec  3 17:04 /etc/sv/postfix/control
661485    4 -rwxr-xr-x   1 root     root           66 Dec  3 17:04 /etc/sv/postfix/control/t
652295    4 drwxr-xr-x   3 root     root         4096 Dec  1 16:41 /etc/sv/postfix/log
661408    4 -rwxr-xr-x   1 root     root           58 Dec  1 16:38 /etc/sv/postfix/log/run
661426    4 drwx------   2 root     root         4096 Dec  4 13:48 /etc/sv/postfix/log/supervise
661458    0 -rw-------   1 root     root            0 Dec  1 16:41 /etc/sv/postfix/log/supervise/lock
661461    4 -rw-r--r--   1 root     root           20 Dec  4 13:48 /etc/sv/postfix/log/supervise/status
661477    0 prw-------   1 root     root            0 Dec  1 16:41 /etc/sv/postfix/log/supervise/ok
661728    4 -rw-r--r--   1 root     root            4 Dec  4 13:48 /etc/sv/postfix/log/supervise/stat
652424    4 -rw-r--r--   1 root     root            5 Dec  4 13:48 /etc/sv/postfix/log/supervise/pid
652426    0 prw-------   1 root     root            0 Dec  1 16:41 /etc/sv/postfix/log/supervise/control
652309    4 drwx------   2 root     root         4096 Dec  4 13:48 /etc/sv/postfix/supervise
654580    0 -rw-------   1 root     root            0 Nov 23 11:20 /etc/sv/postfix/supervise/lock
661489    4 -rw-r--r--   1 root     root           20 Dec  4 13:48 /etc/sv/postfix/supervise/status
661277    0 prw-------   1 root     root            0 Nov 23 11:20 /etc/sv/postfix/supervise/ok
661390    4 -rw-r--r--   1 root     root            4 Dec  4 13:48 /etc/sv/postfix/supervise/stat
661388    4 -rw-r--r--   1 root     root            5 Dec  4 13:48 /etc/sv/postfix/supervise/pid
656413    0 prw-------   1 root     root            0 Dec  3 17:17 /etc/sv/postfix/supervise/control

The supervise sub-directories are automatically set up by runsv.

Board footer

Forum Software