Thursday Jan 08, 2009

Anti-destruction destructive dtrace script and y2k9

A while ago I kludged up this ugly, ugly hack which demonstrates a destructive dtrace script which snapshots the filesystem whenever a destructive command is run (e.g. /usr/bin/rm). It isn't useful except maybe for demos, but the idea could be used for something else. For example, you could snapshot every keystroke on Monday mornings or after a particularly happy New Years Eve especially when transitioning to or from years containing a leap day or leap second...1

#!/usr/sbin/dtrace -s
#pragma D option quiet
#pragma D option destructive

BEGIN
{
  self->interested =0;
}

proc:::exec-success
/(execname =="rm") && (self->interested == 0) && (dirname(curpsinfo->pr_psargs) != ".")/
{
  self->interested = 1 ;
  printf("Someone is trying to delete %s\\n",dirname(curpsinfo->pr_psargs +3));
  printf("%s %d",dirname(curpsinfo->pr_psargs+3),timestamp);
  printf("Snapshotting  %s %d",dirname(curpsinfo->pr_psargs+3),timestamp);
  system("/usr/sbin/zfs snapshot rpool%s@%d",dirname(curpsinfo->pr_psargs+3),timestamp);
  stop();
  system("prun %d", pid);
}

1Sun's JDS 2 Linux distribution was based on a Linux 2.4 kernel and the following version (JDS3 beta) was to be based on a 2.6.19 kernel before Sun decided to drop the Linux kernel and focus on products based around the Solaris kernel. AFAIK the leap second bug appeared in the 2.6.22 Linux kernel. The 5000 year old time keeper at Newgrange also failed to work properly because of a bug caused by the presence of clouds between itself and the sun.

P.S. Don't ask me why we seem to get reoccurring bugs every decade, millennium, leap year and leap-second in what should have been a few score lines of date related code some of which could have been implemented a couple of thousand years ago Maybe Ptolomy's code was refined over a few hundred years without fear of patent reprisals or maybe he just spent more money on development and QA.

Friday Mar 14, 2008

Workaround for nautilus/panel crashes in Nevada 84, 85.

A number of people have encountered a bug which causes nautilus and panel to crash on login, preventing the desktop from being used.

The symptoms are:
  • Nautilus crashes immediately on login, bringing up bug-buddy dialog.
  • Panel crashes immediately after the user clicks the Launch menu.
  • Any application which makes use of gtk icons crashes.

The bug is only experienced on some hardware and may not occur on every install even on hardware where it fails. It is caused by a file access race condition during the post install phase. The file access conflict causes an ASSERT in the gtk-update-icon-cache which forces this application to core during install. The user is left with incomplete and corrupt icon cache which causes failures of all applications depending on the gtk icon cache.

The bug is described in more detail here: 6631419 - gtk-update-icon-cache dies on first boot after install/upgrade

Fortunately, there is a very simple workaround:
  • Login as root
  • Run the following:
    for d in /usr/share/icons/\*; do
           [ -d $d ] &&
                   gtk-update-icon-cache --force $d;
    done
    

This bug is intermittent and is known to exist in Nevada build 84 and build 85. It may exist in earlier builds on some hardware. The GNOME community's decision to enable application cores on ASSERT may have made some of these subtle underlying problems suddenly become much more frequent and obvious. A fix for bug 6631419 is committed for Nevada build 86.

CORRECTION: There was a discussion over enabling fail on assert within the GNOME community, but no change was recently made. The behavior is that on unstable (odd numbered) versions of gnome-session, fail on assert is enabled, but on even numbered builds it isn't.

About

bnitz

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today