Rewriting pup_event in C
If you want to see the notifications you also need to install xfce-notifyd.
I ended up compiling thunar without notification support and disabling thunar's error checking. I have the mount script doing all the error checking and user interaction.
It seems to work ok.
I hacked thunar and xfdesktop to set the environment variable so the gio module is only used for those two programs. I got some hangs with other parts of xfce when I set it globally.
Saluki-022 should be out soon and it will have this stuff to play with.
I ended up compiling thunar without notification support and disabling thunar's error checking. I have the mount script doing all the error checking and user interaction.
It seems to work ok.
I hacked thunar and xfdesktop to set the environment variable so the gio module is only used for those two programs. I got some hangs with other parts of xfce when I set it globally.
Saluki-022 should be out soon and it will have this stuff to play with.
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
Thanks, now I can reproduce your problem.jemimah wrote: If you want to see the notifications you also need to install xfce-notifyd.
I recalled that old bug:
jemimah wrote: But unmounting is segfaulting.Code: Select all
Program received signal SIGSEGV, Segmentation fault. 0x0809e8f3 in ?? () (gdb) bt #0 0x0809e8f3 in ?? () #1 0xb78ecac5 in g_simple_async_result_complete () from /usr/lib/libgio-2.0.so.0 #2 0xb7144524 in pup_volume_monitor_generic_cb (conv=0x8220b80, rcvd_data=0x8183f10, is_new=0, user_data=0x0, conv_user_data=0xb5e07598) at volume_monitor.c:324 #3 0xb713e3f9 in ps_conv_mgr_sorter_cb (sock=0x812f120, data=0xbffff514, user_data=0x81364c0) at conv.c:156 #4 0xb713be02 in pup_sock_common_marshaller (hook=0x0, marshal_data=0xbffff458) at core.c:250 #5 0xb774d91e in g_hook_list_marshal_check () from /usr/lib/libglib-2.0.so.0 #6 0xb713c22b in pup_sock_raise (sock=0x812f120, event=1, has_data=1, cb_data=0xbffff514) at core.c:240 #7 0xb713cff9 in pup_sock_try_receive_block (sock=0x812f120, timer=0x8183f90, data_read=0xbffff558, error=0xbffff5a8) at transfer.c:262 #8 0xb713d172 in pup_sock_receive (sock=0x812f120, timeout=0, num_blocks=4294967295, error=0xbffff5a8) at transfer.c:296 #9 0xb713d33f in pup_sock_input_callback (sock=0x812f120) at transfer.c:324 #10 0xb713c0e9 in pup_sock_event_source_dispatch (source=0x81467e8, callback=0, data=0x0) at core.c:376 #11 0xb775d2cd in g_main_dispatch () from /usr/lib/libglib-2.0.so.0 #12 0xb775def4 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #13 0xb775e0dc in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 #14 0xb775e54d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
Then this function in thunar opened my eyes.akash_rawal wrote: I downloaded the latest thunar, compiled and ran it myself, and found that it was destroying the mount object after every access.
Code: Select all
void
thunar_notify_unmount_finish (GMount *mount)
{
NotifyNotification *notification;
g_return_if_fail (G_IS_MOUNT (mount));
notification = g_object_get_data (G_OBJECT (mount), "thunar-notification");
if (notification != NULL)
{
notify_notification_close (notification, NULL);
g_object_set_data (G_OBJECT (mount), "thunar-notification", NULL);
}
}
It was a reference counting problem, due to which mount objects were destroyed so often. It is fixed now. See first post.
But we had forgotten the question for which the thread was meant.
Should we handle entire event management in C, including kernel module loading?
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
that is likely because puppy has several sleeps to ensure that older boxes have time to settle and pick up the drive (it also reduce cpu load of the daemon process) - *buntu really doesn't care about them.
if you have a good understanding of the kernel processes that occur when a new device is inserted, its much easier to get a simple solution
from my only basic understanding, I first started by monitoring /sys/block/* ... but further poking around reveals /proc/partitions is also updated for "drives"
a simple shell solution is to do something like
in C this could just be equated to fopen /proc/partitions +while fgets line||sleep 1+<code>
the C for looking in /sys/block/*/uevent (the way I do it in shell in jwm_tools) would need dirent, lstat and strtok (to get the = value)
Sorry if this wasn't helpful, i am still writing C as a second language - have to write it shell first and then translate to C
if you have a good understanding of the kernel processes that occur when a new device is inserted, its much easier to get a simple solution
from my only basic understanding, I first started by monitoring /sys/block/* ... but further poking around reveals /proc/partitions is also updated for "drives"
a simple shell solution is to do something like
Code: Select all
tail -f /proc/partitions |while read LINE; do
<code here>
done;
the C for looking in /sys/block/*/uevent (the way I do it in shell in jwm_tools) would need dirent, lstat and strtok (to get the = value)
Sorry if this wasn't helpful, i am still writing C as a second language - have to write it shell first and then translate to C
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
We've got to check whether ubuntu really doesn't care or doesn't need to care.technosaurus wrote: that is likely because puppy has several sleeps to ensure that older boxes have time to settle and pick up the drive (it also reduce cpu load of the daemon process) - *buntu really doesn't care about them.
In most cases it is possible to wait precisely till the device is ready for use. This is usually the fastest solution, as no periodic checks are involved to see whether the device is ready. Also the response is immediate.
Anyways I have very little idea about what to do when a new device is plugged.
e.g. for drives we have to setup corresponding block devices (again, don't know how). After that things are easy: wait for udevd to setup device nodes, use blkid to get partitions and display them on desktop or sidebar, etc.
I updated to 0.0.7 and it seems a lot more stable.
However one weird issue that wasn't there in 0.0.5.
In saluki, if a volume has a label, I mount it on /mnt/<label> instead of /mnt/<devname>.
Thunar still works fine , but in 007 when I click on a drive icon in xfdesktop, it tries to open /mnt/<devname> instead of the correct mount point.
I looked at the code but I couldn't figure out what might have changed this behavior. Actually, I can't figure out why it worked in 005 - it looks like it shouldn't.
However one weird issue that wasn't there in 0.0.5.
In saluki, if a volume has a label, I mount it on /mnt/<label> instead of /mnt/<devname>.
Thunar still works fine , but in 007 when I click on a drive icon in xfdesktop, it tries to open /mnt/<devname> instead of the correct mount point.
I looked at the code but I couldn't figure out what might have changed this behavior. Actually, I can't figure out why it worked in 005 - it looks like it shouldn't.
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
Strange, I cannot reproduce your problem despite all my attempts.
Anyways the volume monitor is designed to handle issues like this. The volume monitor gets all info from /proc/mounts (If that isn't found then it falls back to /etc/mtab and prints a warning to stderr). The only exception (since 0.0.7) is while mounting the drive, but then the monitor is itself executing the mount command with the generated mountpoint.
On mounting a drive with different mountpoint I get correct event:
Even on unmounting and mounting in quick succession I get correct mountpoint (although not correct event):
The source code for all this is found at daemon/mtabdata.c and daemon/monitor.c .
Anyways the volume monitor is designed to handle issues like this. The volume monitor gets all info from /proc/mounts (If that isn't found then it falls back to /etc/mtab and prints a warning to stderr). The only exception (since 0.0.7) is while mounting the drive, but then the monitor is itself executing the mount command with the generated mountpoint.
On mounting a drive with different mountpoint I get correct event:
Code: Select all
# pup-volume-monitor-admin --listen-drv
Volume mounted
Volume sda5:
unix_dev=/dev/sda5
label=WinXP
fstype=ntfs
uuid=545CC7085CC6E438
drv_sysname=sda
mntpnt=/mnt/WinXP
mntflags = 0
Code: Select all
# pup-volume-monitor-admin --listen-drv
Volume remounted
Volume sda5:
unix_dev=/dev/sda5
label=WinXP
fstype=ntfs
uuid=545CC7085CC6E438
drv_sysname=sda
mntpnt=/mnt/WinXP
mntflags = 0
- Attachments
-
- screenshot1.jpg
- thunar too works properly
- (84.83 KiB) Downloaded 421 times
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
I see the performance issue solved in slacko 5.3.1. It detects my pendrive faster than even ubuntu 10.04 did.akash_rawal wrote: I just observed ubuntu lucid setting up my pendrive faster than puppy had ever did.
Seems as if no need to rewrite full event management? Or are there any more performance issues?
Here's the code for mounting.
I know that *input is the device name at this point because the mkdir creates the directory /mnt/<devname>.
I don't use the regular mount command - because I need it to do a few extra things - like mounting in a nonstandard location.
Since the drive has not been mounted yet, it won't be in the mtab.
Once it is in the mtab then the monitor admin reports the correct value.
I've worked around this issue by symlinking /mnt/devname to /mnt/label in the tmount script. But maybe there is a better solution?
EDIT:
I've thought about this some more and I think I'm going to go back to mounting by device name again and symlink to the label name. It doesn't matter much any more since thunar and xfdesktop show the label either way.
Code: Select all
gchar *mntpnt = g_build_filename(PUP_EVENT_MNTPNT, (gchar *) input, NULL);
gchar *cmd = g_strdup_printf("tmount '%s'", vol->unix_dev);
g_mkdir_with_parents(mntpnt, S_IRWXU | S_IRWXG | S_IRWXO);
g_spawn_command_line_sync(cmd, NULL, &stderr_data, &exitcode, &error);
//g_chmod(mntpnt, S_IRWXU | S_IRWXG | S_IRWXO);
g_free(cmd);
I don't use the regular mount command - because I need it to do a few extra things - like mounting in a nonstandard location.
Since the drive has not been mounted yet, it won't be in the mtab.
Once it is in the mtab then the monitor admin reports the correct value.
I've worked around this issue by symlinking /mnt/devname to /mnt/label in the tmount script. But maybe there is a better solution?
EDIT:
I've thought about this some more and I think I'm going to go back to mounting by device name again and symlink to the label name. It doesn't matter much any more since thunar and xfdesktop show the label either way.
Last edited by jemimah on Sun 06 May 2012, 20:06, edited 1 time in total.
My personal thought on rewriting the event manager are this.
You need to get buy-in from Barry to use it in woof if you want it to go mainstream. The best way to do this, IMO, is to start small, debug the heck out of it, and keep it modular.
Then I think udev rules could be developed to handle the desktop icons for ROX.
I'm working on udev rules to keep the fstab up to date (which is all Saluki needs from the event frontend now), but for some reason the blkid command returns incomplete output when run from a script called by udev as opposed to the command line. I can't figure out why.
You need to get buy-in from Barry to use it in woof if you want it to go mainstream. The best way to do this, IMO, is to start small, debug the heck out of it, and keep it modular.
Then I think udev rules could be developed to handle the desktop icons for ROX.
I'm working on udev rules to keep the fstab up to date (which is all Saluki needs from the event frontend now), but for some reason the blkid command returns incomplete output when run from a script called by udev as opposed to the command line. I can't figure out why.
I'm doing exactly this in Fatdog-next. Not yet there yet, but I can already get the icons to display / removed when devices are inserted/removed.jemimah wrote:Then I think udev rules could be developed to handle the desktop icons for ROX.
Check your PATH, make sure blkid you're executing is the full blkid and not busybox blkid.I'm working on udev rules to keep the fstab up to date (which is all Saluki needs from the event frontend now), but for some reason the blkid command returns incomplete output when run from a script called by udev as opposed to the command line. I can't figure out why.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
The correct code is:jemimah wrote: Here's the code for mounting.Code: Select all
gchar *mntpnt = g_build_filename(PUP_EVENT_MNTPNT, (gchar *) input, NULL); gchar *cmd = g_strdup_printf("tmount '%s'", vol->unix_dev); g_mkdir_with_parents(mntpnt, S_IRWXU | S_IRWXG | S_IRWXO); g_spawn_command_line_sync(cmd, NULL, &stderr_data, &exitcode, &error); //g_chmod(mntpnt, S_IRWXU | S_IRWXG | S_IRWXO); g_free(cmd);
Code: Select all
gchar *mntpnt;
if (vol->label && (g_strcmp0(vol->label, "") != 0))
mntpnt = g_build_filename(PUP_EVENT_MNTPNT, vol->label, NULL);
else
mntpnt = g_build_filename(PUP_EVENT_MNTPNT, (gchar *) input, NULL);
-
- Posts: 229
- Joined: Wed 25 Aug 2010, 15:38
- Location: ISM Dhanbad, Jharkhand, India
I get a segfault during startup occaisionally.
Using g_strrstr instead of strstr seems to resolve whatever the issue is.
Code: Select all
Program received signal SIGSEGV, Segmentation fault.
0xb7d77358 in strstr () from /lib/libc.so.6
(gdb) bt
#0 0xb7d77358 in strstr () from /lib/libc.so.6
#1 0x0804b5d0 in volume_new_from_blkid_dev (volumes=0x804fc70,
drives=0x804fc38, dev=0x8053110, cache=0x8052890, udev_ctx=0x8050600)
at volume.c:72
#2 0x0804bf1c in monitor_fill_data (mon=0x8051800) at monitor.c:86
#3 0x0804c6f8 in server_new (
address=0x804cb3c "/tmp/pup_volume_monitor_socket", ctx=0x0) at server.c:49
#4 0x0804c77c in main (argc=<value optimized out>, argv=<value optimized out>)
at main.c:12
Using g_strrstr instead of strstr seems to resolve whatever the issue is.
Thanks, that helps a lot.akash_rawal wrote:The correct code is:jemimah wrote: Here's the code for mounting.Code: Select all
gchar *mntpnt = g_build_filename(PUP_EVENT_MNTPNT, (gchar *) input, NULL); gchar *cmd = g_strdup_printf("tmount '%s'", vol->unix_dev); g_mkdir_with_parents(mntpnt, S_IRWXU | S_IRWXG | S_IRWXO); g_spawn_command_line_sync(cmd, NULL, &stderr_data, &exitcode, &error); //g_chmod(mntpnt, S_IRWXU | S_IRWXG | S_IRWXO); g_free(cmd);
Rest of the code remains as original. This will also save you from extra hassle of finding labels.Code: Select all
gchar *mntpnt; if (vol->label && (g_strcmp0(vol->label, "") != 0)) mntpnt = g_build_filename(PUP_EVENT_MNTPNT, vol->label, NULL); else mntpnt = g_build_filename(PUP_EVENT_MNTPNT, (gchar *) input, NULL);
I do like to use tmount (which is adapted from drive_all) because it does things like offer to fuser the drive when it can't be unmounted.
It's not a PATH issue. Blkid correctly returns info about every drive except the one in question. It's bizarre.akash_rawal wrote:udev removes the entire environment , including PATH variable. You have to re-export it yourself or use full path to blkid.jemimah wrote: but for some reason the blkid command returns incomplete output when run from a script called by udev as opposed to the command line. I can't figure out why.
The daemon crashes when loopback devices are unmounted.
#
Code: Select all
Volume loop5:
unix_dev=/dev/loop5
label=(null)
fstype=squashfs
uuid=(null)
drv_sysname=(null)
mntpnt=/mnt/+initrd+mnt+dev_save+blender-2.61-i686.sfs
mntflags = 0 | VOLUME_IS_READ_ONLY
*** glibc detected *** pup-volume-monitor: double free or corruption (fasttop): 0x080762a0 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7552c9d]
/lib/libc.so.6[0xb7554247]
/lib/libc.so.6(cfree+0x62)[0xb7556df2]
/usr/lib/libglib-2.0.so.0(g_free+0x27)[0xb76c35e6]
/usr/lib/libpupevent.so.0(volume_free_mem+0x5c)[0xb766d67c]
pup-volume-monitor[0x804b565]
pup-volume-monitor[0x804bccf]
/usr/lib/libglib-2.0.so.0[0xb76e5cf8]
/usr/lib/libglib-2.0.so.0[0xb76e56db]
/lib/libpthread.so.0[0xb762f02f]
/lib/libc.so.6(clone+0x5e)[0xb75b5d1e]
======= Memory map: ========
08048000-0804d000 r-xp 00000000 07:01 216 /initrd/pup_rw/usr/bin/pup-volume-monitor
0804d000-0804e000 rwxp 00004000 07:01 216 /initrd/pup_rw/usr/bin/pup-volume-monitor
0804e000-08093000 rwxp 00000000 00:00 0 [heap]
b6b00000-b6b21000 rwxp 00000000 00:00 0
b6b21000-b6c00000 ---p 00000000 00:00 0
b6cd5000-b6ce1000 r-xp 00000000 07:00 7568 /initrd/pup_ro2/usr/lib/libgcc_s.so.1
b6ce1000-b6ce2000 rwxp 0000b000 07:00 7568 /initrd/pup_ro2/usr/lib/libgcc_s.so.1
b6ce2000-b6ce3000 ---p 00000000 00:00 0
b6ce3000-b74e5000 rwxp 00000000 00:00 0
b74e5000-b74e8000 r-xp 00000000 07:00 9932 /initrd/pup_ro2/lib/libuuid.so.1.3.0
b74e8000-b74e9000 rwxp 00002000 07:00 9932 /initrd/pup_ro2/lib/libuuid.so.1.3.0
b74e9000-b7623000 r-xp 00000000 07:00 9861 /initrd/pup_ro2/lib/libc-2.10.1.so
b7623000-b7625000 r-xp 0013a000 07:00 9861 /initrd/pup_ro2/lib/libc-2.10.1.so
b7625000-b7626000 rwxp 0013c000 07:00 9861 /initrd/pup_ro2/lib/libc-2.10.1.so
b7626000-b7629000 rwxp 00000000 00:00 0
b7629000-b763c000 r-xp 00000000 07:00 9933 /initrd/pup_ro2/lib/libpthread-2.10.1.so
b763c000-b763d000 r-xp 00012000 07:00 9933 /initrd/pup_ro2/lib/libpthread-2.10.1.so
b763d000-b763e000 rwxp 00013000 07:00 9933 /initrd/pup_ro2/lib/libpthread-2.10.1.so
b763e000-b7640000 rwxp 00000000 00:00 0
b7640000-b7666000 r-xp 00000000 07:00 9865 /initrd/pup_ro2/lib/libm-2.10.1.so
b7666000-b7667000 r-xp 00025000 07:00 9865 /initrd/pup_ro2/lib/libm-2.10.1.so
b7667000-b7668000 rwxp 00026000 07:00 9865 /initrd/pup_ro2/lib/libm-2.10.1.so
b7668000-b766f000 r-xp 00000000 07:01 356 /initrd/pup_rw/usr/lib/libpupevent.so.0.0.0
b766f000-b7670000 rwxp 00006000 07:01 356 /initrd/pup_rw/usr/lib/libpupevent.so.0.0.0
b7670000-b7671000 rwxp 00000000 00:00 0
b7671000-b7794000 r-xp 00000000 07:00 7492 /initrd/pup_ro2/usr/lib/libglib-2.0.so.0.3200.1
b7794000-b7795000 rwxp 00122000 07:00 7492 /initrd/pup_ro2/usr/lib/libglib-2.0.so.0.3200.1
b7795000-b7796000 rwxp 00000000 00:00 0
b7796000-b779c000 r-xp 00000000 07:00 9898 /initrd/pup_ro2/lib/librt-2.10.1.so
b779c000-b779d000 r-xp 00005000 07:00 9898 /initrd/pup_ro2/lib/librt-2.10.1.so
b779d000-b779e000 rwxp 00006000 07:00 9898 /initrd/pup_ro2/lib/librt-2.10.1.so
b779e000-b779f000 r-xp 00000000 07:00 8151 /initrd/pup_ro2/usr/lib/libgthread-2.0.so.0.3200.1
b779f000-b77a0000 rwxp 00000000 07:00 8151 /initrd/pup_ro2/usr/lib/libgthread-2.0.so.0.3200.1
b77a0000-b77b8000 r-xp 00000000 07:00 9888 /initrd/pup_ro2/lib/libblkid.so.1.1.0
b77b8000-b77ba000 rwxp 00017000 07:00 9888 /initrd/pup_ro2/lib/libblkid.so.1.1.0
b77ba000-b77c6000 r-xp 00000000 07:00 9921 /initrd/pup_ro2/lib/libudev.so.0.11.1
b77c6000-b77c7000 rwxp 0000b000 07:00 9921 /initrd/pup_ro2/lib/libudev.so.0.11.1
b77c7000-b77c8000 rwxp 00000000 00:00 0
b77c8000-b77e2000 r-xp 00000000 07:00 9953 /initrd/pup_ro2/lib/ld-2.10.1.so
b77e2000-b77e3000 r-xp 00019000 07:00 9953 /initrd/pup_ro2/lib/ld-2.10.1.so
b77e3000-b77e4000 rwxp 0001a000 07:00 9953 /initrd/pup_ro2/lib/ld-2.10.1.so
bfcce000-bfcef000 rw-p 00000000 00:00 0 [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]
Aborted
Sigh http://forum.tinycorelinux.net/index.php?topic=12176.0. Some solution here: http://www.linuxquestions.org/questions ... ve-930081/.jemimah wrote:It seems like some sort of probing needs to happen for optical drives. Udev doesn't seem to generate any events when a CD/DVD is inserted.
Also I'm not sure how to get audio CDs to show up on the desktop. They don't seem to have any volumes associated with them.
I ended up running cddetect_quick once every few seconds to generate udev events.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]