dev-zero
commented
7 years ago Can you manually remove the lock file please?
It seems that an earlier run of Sepiola left it...
Closed meichenberger closed 7 years ago
dev-zero
commented
7 years ago Can you manually remove the lock file please?
It seems that an earlier run of Sepiola left it...
dev-zero
commented
7 years ago Respectively, check the PID mentioned in the lock file. Could be a duplicate of issue #11
meichenberger
commented
7 years ago And where would that lock file be? I checked:
[eichi@quito run]$ pwd
/var/run
[eichi@quito run]$ ls -al
total 56
drwxr-xr-x. 43 root root 1260 Dec 23 10:23 .
dr-xr-xr-x. 18 root root 4096 Dec 6 21:09 ..
drwxr-xr-x. 2 root root 100 Dec 23 00:05 abrt
-rw-------. 1 root root 11 Dec 23 00:05 alsactl.pid
-rw-r--r--. 1 root root 4 Dec 23 00:05 atd.pid
-rw-r--r--. 1 root root 4 Dec 23 00:05 auditd.pid
drwxr-xr-x. 2 avahi avahi 80 Dec 23 00:05 avahi-daemon
drwxr-x---. 2 chrony chrony 60 Dec 23 10:03 chrony
-rw-r--r--. 1 root root 4 Dec 23 00:05 chronyd.pid
drwxr-xr-x. 2 root root 80 Dec 23 10:03 chrony-helper
drwxr-xr-x. 2 root root 80 Dec 23 00:05 console
-rw-r--r--. 1 root root 4 Dec 23 00:05 crond.pid
----------. 1 root root 0 Dec 23 00:05 cron.reboot
drwxr-xr-x. 3 root lp 80 Dec 23 00:05 cups
drwxr-xr-x. 2 root root 60 Dec 23 00:05 dbus
-rw-r--r--. 1 root root 5 Dec 23 10:03 dhclient6-wlp3s0.pid
-rw-r--r--. 1 root root 5 Dec 23 10:03 dhclient-wlp3s0.pid
prw-------. 1 root root 0 Dec 23 00:04 dmeventd-client
prw-------. 1 root root 0 Dec 23 00:04 dmeventd-server
drwxr-xr-x. 2 root root 40 Dec 23 00:05 faillock
drwxr-x---. 2 root root 40 Dec 23 10:03 firewalld
-rw-------. 1 root root 4 Dec 23 00:05 gssproxy.pid
srw-rw-rw-. 1 root root 0 Dec 23 00:05 gssproxy.sock
drwxr-xr-x. 4 root root 100 Dec 23 00:04 initramfs
drw-r--r--. 2 root root 40 Dec 23 00:05 libgpod
drwxr-xr-x. 7 root root 160 Dec 23 00:05 lock
drwxr-xr-x. 2 root root 40 Dec 23 00:04 log
drwx------. 2 root root 80 Dec 23 00:04 lvm
drwxr-xr-x. 2 mysql mysql 40 Dec 23 00:05 mariadb
srwxr-xr-x. 1 root root 0 Dec 23 00:05 mcelog-client
-rw-r--r--. 1 root root 3 Dec 23 00:05 mcelog.pid
drwx--x---. 2 root root 40 Dec 23 00:05 mdadm
drwxr-xr-x. 2 root root 60 Dec 23 00:04 mount
drwxr-xr-x. 2 mysql mysql 40 Dec 23 00:05 mysqld
drwxrwxr-x. 2 root root 40 Dec 23 00:05 netreport
drwxr-xr-x. 2 root root 80 Dec 23 10:03 NetworkManager
drwx--x---. 2 root openvpn 40 Dec 23 00:05 openvpn
drwxr-xr-x. 2 root root 40 Dec 23 00:05 pluto
drwxr-xr-x. 2 root root 40 Dec 23 00:05 plymouth
drwxr-xr-x. 2 root root 40 Dec 23 00:05 ppp
drwxr-x---. 2 root root 40 Dec 23 00:05 pptp
drwx------. 2 rpc rpc 40 Dec 23 00:05 rpcbind
srw-rw-rw-. 1 root root 0 Dec 23 00:04 rpcbind.sock
drwxr-xr-x. 2 root root 40 Dec 23 00:05 samba
drwx--x--x. 2 root root 60 Dec 23 00:05 sddm
drwxr-xr-x. 2 root root 40 Dec 23 00:05 sepermit
drwxr-xr-x. 2 root root 40 Dec 23 00:05 setrans
-rw-------. 1 root root 4 Dec 23 00:05 sm-notify.pid
drwxr-xr-x. 2 root root 40 Dec 23 00:05 spice-vdagentd
-rw-r--r--. 1 root root 4 Dec 23 00:05 sshd.pid
drwx--x--x. 3 root root 60 Dec 23 00:05 sudo
drwx------. 2 root root 40 Dec 23 00:05 svnserve
drwxr-xr-x. 2 root root 60 Dec 23 00:05 sysconfig
-rw-------. 1 root root 3 Dec 23 00:05 syslogd.pid
drwxr-xr-x. 17 root root 420 Dec 23 00:05 systemd
drwxr-xr-x. 2 root root 60 Dec 23 00:04 tmpfiles.d
drwxr-xr-x. 7 root root 160 Dec 23 13:41 udev
drwx------. 2 root root 40 Dec 23 00:05 udisks2
drwxr-xr-x. 3 root root 60 Dec 23 00:05 user
-rw-rw-r--. 1 root utmp 3072 Dec 23 13:45 utmp
drwxr-xr-x. 2 root root 40 Dec 23 00:05 vpnc
drwxr-xr-x. 2 root root 40 Dec 23 00:05 xl2tpd
-rw-------. 1 root root 0 Dec 23 00:05 xtables.lock
[eichi@quito run]$Ooops, just found it in the .sepiola directory. Sorry!
And yes, Sepiola starts now and I could execute the back successfully.
But after closing Sepiola, the lock file stays there, even though no process is running:
[eichi@quito .sepiola]$ pwd
/home/eichi/.sepiola
[eichi@quito .sepiola]$ ls -al
total 7644
drwxrwxr-x. 3 eichi eichi 4096 Dec 23 13:50 .
drwxr-xr-x. 72 eichi eichi 8192 Dec 23 00:05 ..
-rw-rw-r--. 1 eichi eichi 1337198 Dec 23 13:49 backupContent
-rw-rw-r--. 1 eichi eichi 1744 Dec 23 13:49 config
-rw-rw-r--. 1 eichi eichi 1513 Dec 23 13:49 config_appData
-rw-rw-r--. 1 eichi eichi 60 Dec 23 13:49 includes
-rw-rw-r--. 1 eichi eichi 4 Dec 23 13:50 lock
-rw-rw-r--. 1 eichi eichi 2555484 Dec 23 13:49 metadata_unix
-rw-------. 1 eichi eichi 2555298 Dec 23 13:49 metadata_unix_tmp
-rw-rw-r--. 1 eichi eichi 1335199 Dec 23 13:50 sepiola.log
drwxrwxr-x. 2 eichi eichi 37 Dec 23 13:49 .ssh
[eichi@quito .sepiola]$ ps auxf | grep sepio
eichi 7816 0.0 0.0 118520 940 pts/1 S+ 13:51 0:00 \_ grep --color=auto sepio
[eichi@quito .sepiola]$ Checked the pid:
[eichi@quito .sepiola]$ ps auxf | grep sepio
eichi 7816 0.0 0.0 118520 940 pts/1 S+ 13:51 0:00 \_ grep --color=auto sepio
[eichi@quito .sepiola]$ cat lock
7760[eichi@quito .sepiola]$ ps auxf | grep 7760
eichi 7847 0.0 0.0 118520 904 pts/1 S+ 13:53 0:00 \_ grep --color=auto 7760
[eichi@quito .sepiola]$ right, my bad: Sepiola does not remove the lock file when done. On startup, Sepiola checks the PID inside the lock file and if there is a process running under that PID it assumes it to be an instance of Sepiola (which in your case was likely another process which got the same PID as the Sepiola you ran on Dec 16.). If we are going to keep the lock file like that, we have to also check the executable name, as described in issue #11
dev-zero
commented
7 years ago ok, closing this as a duplicate of issue #11 (which is now in milestone 2.5)
Sepiola gave me the following message:
I checked if I had another process running:
The content of my .sepiola folder (used the last time on the 13th of December 2016 with the failed update today):
Trying to re-run Sepiola again, led to the same behaviour.
Sepiola before Upgrade: sepiola-2.3.5-15-g1a2b904-Linux-x86_64 Sepiola after Upgrade: sepiola-2.3.5-23-g1243b77-Linux-x86_64