View Issue Details

IDProjectCategoryView StatusLast Update
0000142tcsh[All Projects] Generalpublic2020-02-19 14:06
ReporterbitstreamoutAssigned Tochristos 
PrioritynormalSeveritymajorReproducibilitysometimes
Status assignedResolutionopen 
Platformx86_64OSlinuxOS Version
Product Version6.22.02 
Target VersionFixed in Version 
Summary0000142: Dot locking sometimes does block after reboot
DescriptionDuring reboot it happens sometimes that one of my open tcsh sesssions does not get enough time to write out history and got killed by systemd before the dot lock file had been removed. It would be a a solution to combine the dot locking method with fcntl(F_SETLKW/F_UNLCK) as this does work over NFS at least for Linux. This also would allow to avoid polling due waiting on F_SETLKW ...
Steps To ReproduceOpen several tcsh sessions, do some work therein, and reboot
TagsNo tags attached.

Activities

christos

2020-02-16 16:15

manager   ~0003371

Perhaps it is better to give up with a message to the user instead of getting stuck... I don't want to add more complexity to the locking. The point of dotlock is to not use the fcntl() based in the first place which is even less reliable over NFS...

bitstreamout

2020-02-17 10:05

reporter   ~0003374

Hmmm ... on Linux based systems itz is possible to determine the process which holds the file descriptor. But this requires to parse /proc/ ... on the other hand most modern Linux systems have a tmpfs based /dev/shm worls writable and sticky directory which not only tmpfs but also a local file system. Besdide this : I had used some years a patch set from redhat with fcntl() based locking which never had shown problems over NFS ... only the porting to the next tcsh version had become complicated and fragile with increasing version number.

christos

2020-02-17 17:53

manager   ~0003375

Last edited: 2020-02-17 17:54

View 2 revisions

Yes, but remember tcsh runs on other OS's including windows... And this is a corner case that does not usually happen. Doesn't systemd have a way to increase the grace time it waits before killing the processes?

bitstreamout

2020-02-18 08:06

reporter  

tcsh-6.22.02-local-dotlock.dif (1,861 bytes)

bitstreamout

2020-02-18 08:06

reporter   ~0003376

Not really as the most tcsh process do poll by sleeping within usleep() ... using F_SETLKW would avoid this but requires interrupt handling. Currently I use a workaround, which is use /dev/shm as this file system is always fresh because it is tmpfs based

christos

2020-02-18 20:20

manager   ~0003377

What happens when the home directory is mounted over NFS and shared between different hosts? How will the other systems see the tmpfs lock? Let's try to treat the cause (systemd killing tcsh too quickly) instead of the symptoms (tcsh leaving a stray lock file around because it got kill -9'ed).

bitstreamout

2020-02-19 07:54

reporter   ~0003379

Good point, personal I use different histories for different hosts. The fcntl() method had worked here over years without any problems, that means I had never seen any problems nor had got any bug reports. Maybe this is also Linux specific ... only rebooted (linux based) NFS servers may cause that a lock gets lost. For this a local tcsh has to write out its history at the same time as the NFS server is rebooted

bitstreamout

2020-02-19 10:05

reporter   ~0003380

in create_exclusive(): How about open the fname after link(path, fname) and then unlink(fname)? As long as the process hold the file descriptor the dot lock file i That means that if the process gets kill-9'ed the file will disapear with the last open file descriptor

tcsh-6.22.02-local-dotlock-2.dif (2,594 bytes)

christos

2020-02-19 13:43

manager   ~0003381

Then locking does not work. Another process can do the same (on the same or a different machine). This is the whole idea behind dot locking: that you can only touch the file once you've established you are the owner (by creating the link and making sure that the link count is 2).

bitstreamout

2020-02-19 14:00

reporter   ~0003382

Hmm ... here it seems to work at least on the same machine

```
openat(AT_FDCWD, "/suse/werner/.tcsh/.noether.d574", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_SYNC, 0200) = 3
close(3) = 0
link("/suse/werner/.tcsh/.noether.d574", "/suse/werner/.tcsh/werner@noether.lock") = -1 EEXIST (File exists)
unlink("/suse/werner/.tcsh/.noether.d574") = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({tv_sec=0, tv_nsec=100000000}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT TERM CHLD TSTP TTIN TTOU], [], 8) = 0
uname({sysname="Linux", nodename="noether", ...}) = 0
getpid() = 11676
openat(AT_FDCWD, "/suse/werner/.tcsh/.noether.2be3e", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_SYNC, 0200) = 3
close(3) = 0
link("/suse/werner/.tcsh/.noether.2be3e", "/suse/werner/.tcsh/werner@noether.lock") = 0
openat(AT_FDCWD, "/suse/werner/.tcsh/werner@noether.lock", O_WRONLY|O_EXCL|O_SYNC) = 3
unlink("/suse/werner/.tcsh/werner@noether.lock") = 0
stat("/suse/werner/.tcsh/.noether.2be3e", {st_mode=S_IFREG|0200, st_size=0, ...}) = 0
unlink("/suse/werner/.tcsh/.noether.2be3e") = 0
```

```
openat(AT_FDCWD, "/suse/werner/.tcsh/.noether.dc5c", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_SYNC, 0200) = 3
close(3) = 0
link("/suse/werner/.tcsh/.noether.dc5c", "/suse/werner/.tcsh/werner@noether.lock") = 0
openat(AT_FDCWD, "/suse/werner/.tcsh/werner@noether.lock", O_WRONLY|O_EXCL|O_SYNC) = 3
unlink("/suse/werner/.tcsh/werner@noether.lock") = 0
stat("/suse/werner/.tcsh/.noether.dc5c", {st_mode=S_IFREG|0200, st_size=0, ...}) = 0
unlink("/suse/werner/.tcsh/.noether.dc5c") = 0
```

christos

2020-02-19 14:06

manager   ~0003383

The point is that at the time you remove the lock there could be another process (on a different machine perhaps) who owns the lock and is currently writing the file. The lock is a sign that the file is busy. If you remove it indiscriminately there is no point in creating it in the first place.

Issue History

Date Modified Username Field Change
2020-02-14 14:32 bitstreamout New Issue
2020-02-16 16:13 christos Assigned To => christos
2020-02-16 16:13 christos Status new => assigned
2020-02-16 16:15 christos Status assigned => feedback
2020-02-16 16:15 christos Note Added: 0003371
2020-02-17 10:05 bitstreamout Note Added: 0003374
2020-02-17 10:05 bitstreamout Status feedback => assigned
2020-02-17 17:53 christos Note Added: 0003375
2020-02-17 17:54 christos Note Edited: 0003375 View Revisions
2020-02-18 08:06 bitstreamout File Added: tcsh-6.22.02-local-dotlock.dif
2020-02-18 08:06 bitstreamout Note Added: 0003376
2020-02-18 20:20 christos Note Added: 0003377
2020-02-19 07:54 bitstreamout Note Added: 0003379
2020-02-19 10:05 bitstreamout File Added: tcsh-6.22.02-local-dotlock-2.dif
2020-02-19 10:05 bitstreamout Note Added: 0003380
2020-02-19 13:43 christos Note Added: 0003381
2020-02-19 14:00 bitstreamout Note Added: 0003382
2020-02-19 14:06 christos Note Added: 0003383