I guess that makes the 'Edit config.ini' option in Jemplode/Emplode kinda useless, as that only works if you have the ability to sync. (Chicken/Egg)

yes, but i was asking what the advantage of not using the drive0 and drive1 partitions in the first place. updates don't touch what's there.

I need to stop posting when I'm tired....

Point taken.

However, after the laucher functionality goes into hijack 90% of users won't have the need for an application to boot on every AC powerup.

But yes, you are probably right that if for some reason you did need to start something on every AC boot, the main partion is the better place for it. Are there any other examples people can think of besides someone who wants to have telnetd running on AC power on every boot?

I suppose if I were clever enough to ensure all user apps are started in a common process group or something, then Hijack could kill them all on request.. But many daemons fork and then drop their groups IDs, so that wouldn't work..

What exactly is the problem, anyway?

I don't use third party apps myself (anything I need, I build into Hijack.. that's why it exists!), so perhaps somebody else could explain exactly how an app that was started from /drive0/ prevents sync from working..?

-ml

IIRC, it's because the process' working directory is in a filesystem that being (re)mounted, and mount doesn't like that. If you make sure that it starts up with a pwd of /, then that won't happen.

No, I don't believe that. CWD is '/' for programs started by Hijack.

Here, collect some info for us: run a third-party app from Hijack, and then surf to /proc/nnnn/, where nnnn is the PID of the app. Collect everything from there and show us what you find for CWD et al.

Thanks

My fault. That was (often) the problem before. I haven't even installed Hijack v30<whatever> yet, as I don't honestly run any additional programs on the empeg.

If you can't get around it by not starting anything (by default) on AC power (that is, using, hijack to launch "occasional use" things), I'd recomend just commenting out the offending ;@EXECs and rebooting before syncing.


Messy - manual commenting out on every sync is going to be as (if not more) painful than reconfiguring apps after an occasional upgrade. Automagically commenting them out is going to require careful coding in JEmplode to ensure that it handles already commented out EXEC lines correctly afterwards.

And it would be a delaying factor anyway - we'd need to reboot after disabling apps, which would then need JEmplode to re-read the database.

To do this right, we need to have a cohesive strategy that utilises JEmplode, hijack and on-player utilities when appropriate.

I'd suggest that the specs for this strategy should include as a base. I apologize in advance for being presumptious about changes needed to other peoples' work.

1) Initial setup (from a hijacked but otherwise 'vanilla' Official release) should be a one button click operation in JEmplode. (I'll accept 2 buttons if you count 'Sync' )
1.1) This setup should be repeatable without loss of any existing data after an official upgrade.
1.2) The setup should include on the empeg any binaries or shell scripts that JEmplode needs to manipulate and install packages.

2) The strategy should allow for (non-application related) syncs to occur from the Empeg-offical Emplode;
2.1) without any modification of config.ini
2.2) without any changes to Emplode itself
2.3) without adding any reboots.

I think that if we can get those first specs well understood, and a strategy to implement them, then it makes the other specs much easier to implement;

3) Suitable package system facilitating;
3.1) Point and click application install.
3.2) Point and click application upgrades, including intelligent handling of application config files.
3.3) Removal of packages... (allow config files to remain? Make that optional?)
3.4) config.ini EXEC lines. (e.g, provide a list of selectable options)
3.5) Package must include a simple method of versioning that JEmplode can read.

4) JEmplode should interact with the package and associated on-empeg utilities to perform the install, configuration or uninstall.
4.1) Should be capable of locating the package on the local filesystem.
4.2) Should be able to parse the package for version and configuration information.
4.3) Should be able to present user with selectable config.ini options based upon package recommendations. User should be able to define their own selection if desired.
4.4) JEmplode should be capable of (optionally?) displaying installed apps, and associated config files in the tree.
4.5) Should interact with the on-empeg utilities to install, (intelligently) upgrade or remove packages, including config.ini changes.
4.6) Should be able to temporarily disable application (through config.ini change) without removing it.


As I said, I think that this needs to be a 3 pronged approach to be really successful - and will require co-operation between efforts would be required.

I don't have any good info either, as I haven't experienced the sync lockup in a long while, but then again perhaps that's because I've actively tried to avoiding it. It does exist though, but I've just assumed it had something to do with running any programs from the music drives during a sync. It might only be those that have open files though, that would make more sense. If that were the case it'd be even less of a problem.

I'll leave this to someone who has has the problem to play with further.

John

That took a while to type up.... I hope it wasn't made redundant..

wow, that looks like one of my long winded posts!

I'm still not convinced that we can't avoid the sync problem altogether. I wish I had an empeg nearby, as no one seems to know what the cause of these lock ups is and I have not gotten one in several months.

These are good ideas, yes. But it be really nice to avoid any commenting business at all. That part of my comment earlier was incredibly poorly thought out. Let's first see if we can't eliminate the situation that causes the lockups in a direct way before involving Emplode or comenting or anything like that.

So can anyone give actual evidence of what causes a lock up? I'm betting that it's only when a running app has a resource (file) open on the music partition, in which case it seems we could just eliminate that situation from occuring by default on AC boots.

If I’m following the topic correctly, my 2 cents would be not to include the functions for setup 3rd party programs in Jemplode. I would rather a separate package manager. Wasn’t smu working on this before? His idea, maybe modified a little bit, would be great. I never sync my music database with jemplode, nothing against the java version of emplode, but I just don’t trust it with my music database. I’ll use it for the animation editor, and downloading tracks, and that’s about it. I’m actually fine with ae? (crappy vi like empeg text editor)

I had forgotten about the disadvantage of not being able to sync while a program is running on the music partition.

So had I. Sticky problem.

For me, it's fine to run all my apps in DC mode only, but what about the folks who sync with the player in their car (wirelessly or via a laptop)?

I wonder if there's any way to code the apps so that they just don't have this problem. Or perhaps there's a way for Hijack to know when it gets a reboot-request from synching software and Do The Right Thing with regard to mounting the drives.

Heck, I'd like to see Hijack do that anyway... If I set RW while a program is running, the subsequent RO fails (without an error message by Hijack, I might add ). It would be neat if Hijack could Do The Right Thing in that situation, too.

The theoretical package manager referenced in this thread and discussed here is functionally completely separate from JEmplode syncs. It changes nothing whether it would be packaged with JEmplode or not. (In fact, it would be trivial to separate if you really wanted it so.)

As for this sync lockup business, pay little attention yet. I'm not sure we (I?) know what we're talking about anymore...

Can anyone confirm that a program running from the music drive, but that does not have any files on the music drive open still blocks a sync?

That's the question of the hour...

...I can't handle the suspense anymore. I'm seriously *walking* one mile to get an empeg to try this out. Not kidding...

I wonder if there's any way to code the apps so that they just don't have this problem.


Well there is, but any solution that we implement shouldn't really rely on a 3rd party app being correctly coded in order to avoid an fsck. (If we can possibly avoid it).

Mmm.. "open files" (for WRITE or READ/WRITE would do it. To prevent this, GPSapp and friends should ensure that their files are only open with RD_ONLY access. But then, that should be the case already, since the filesystem is read-only to begin with.

The info in /proc/nn/ will tell the true story..

Ofcourse I'm running from /programs0, but here is the relevant proc/nn info. My guess is that at the end of a sync, the software actually does "umount /drive0 ; mount -oro /drive0" instead of "mount -oremount,ro /drive0" and the umount fails because the executable image still has a reference on the filesystem.
(btw. I was logged in with telnet, which explains the two sockets and /dev/ptyp0)

sh-2.03# ls -lR /proc/12 

/proc/12:

lrwx------    1 0        0               0 Jan 25 17:37 cwd -> /

lrwx------    1 0        0               0 Jan 25 17:37 exe -> /programs0/telnetd

lrwx------    1 0        0               0 Jan 25 17:37 root -> /



/proc/12/fd:

lrwx------    1 0        0              64 Jan 25 17:37 0 -> /dev/ttyS1

lrwx------    1 0        0              64 Jan 25 17:37 1 -> /dev/ttyS1

lrwx------    1 0        0              64 Jan 25 17:37 2 -> /dev/ttyS1

lrwx------    1 0        0              64 Jan 25 17:37 3 -> socket:[3]

lrwx------    1 0        0              64 Jan 25 17:37 4 -> socket:[21]

lrwx------    1 0        0              64 Jan 25 17:37 5 -> /dev/ptyp0

Okay, remind me in a day or two to instrument the mount/remount calls in the kernel so we can see exactly what the player is doing (or we could just run strace on the player, but I think it would be serial-port bound..).

Back to the workshop now.. gotta get these docks out.

-ml

I got similar results in the /proc/nn/ dir for telnetd.

I did confirm that a sync fails even if the program does not have any files open during the sync. The sync the fails with the emplode message: Syncronization faid while checking media, 0xc0041010.

I couldn't interpret anything from roger's error code table from that one. I don't think it's in there.

This however is the serial output when the sync fails:

Adding Swap: 16596k swap-space (priority -3)
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/
hda4 is mounted.
Restored terminal settings
Remounting first music partition read-only
Remounting second music partition read-only
Restart code received
Starting player

Maybe that "ext2fs_check_if_mount" line will tell you something. Let me know if I can help with anything else.

John

I did the strace,

oldumount("/drive0");
fork(); // runs some program that returns "/dev/hda4: clean, 5547/" probably fsck
mount("/dev/hda4","/drive0","ext2",MS_RDONLY|0xc0ed0000,0x210f65c)
// does some more stuff
mount("/dev/hda4","/drive0","ext2",MS_REMOUNT|0xc0ed0000,0x210f65c)
// does a lot more stuff (probably the actual sync)
mount("/dev/hda4","/drive0","ext2",MS_RDONLY|MS_REMOUNT|0xc0ed0000,0x210f65c)

So it looks like we're being bitten by the fact that we can't perform a filesystem check on a mounted filesystem. The actual sync should be just fine.

At the end of the sync, the player kills itself and is restarted. Hmm, would it be possible to kill any process that has an open file reference to the filesystem at the time of umount. Then we could use ;@EXEC /drive0/bin/telnetd and it would just get killed when the sync is started, but will restart whenever the player comes back.

Mmmm.. there's nothing technically wrong with doing the fsck on a live READONLY filesystem, at least not in most versions of the kernel (think.. root filesystem check at boot time.. it's always mounted RO at the time).

If that's all that's wrong, we could just intercept "oldumount()" in-kernel, verify it's coming from the player binary, and then just ignore it (or replace it with a mount READ-ONLY).

-ml

I suppose there are two classes of filesystem repairs.. those that are fine to proceed with, and those that require rebooting if the filesystem was mounted RO during the check.. the exit status from e2fsck indicates which type occured. This could be a bit of a snag for us.. but a bit of thought will likely produce a workaround of some sort.

-ml

a workaround of some sort

Wouldn't it be possible to intercept the umount, check for open files on the two music filesystems and if there are any kill the process holding the file open before unmounting? Not the most friendly solution, but a lot simpler than tweaking a lot of existing software to avoid the problem.

-Mike

Yeah, that's what I was thinking.