Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Currently on Ubuntu Linux, but I noticed this on other OS's too. Apparently any user can execute the sync command, but why is this? I can only see the disadvantage: system slow down due to unnecessary disk writes.

Why can every user execute sync?

share|improve this question
1  
My question on this topic would be: Is there even a way to prevent users from using sync()? –  Bonsi Scott Dec 1 '12 at 23:52
    
@BonsiScott Sure, you can remove the permission bits from the executable. But I don't know if something will get broken when you do that. –  jippie Dec 1 '12 at 23:54
    
Not only can any user run sync, you also don't need an account. The account 'sync' runs /bin/sync as its shell, so you can sync without logging in. –  camh Dec 2 '12 at 9:44
    
What is that useful for? BTW there is no password on the sync account on the box I am currently working on, so that won't work. –  jippie Dec 2 '12 at 10:10
    
It is recommended for production systems to lower the wait-time between sync-calls (e.g. on HP-Unix). The reason is to avoid unnecessary waits due to masses of outstanding writes being written to disk all at once. –  Nils Dec 2 '12 at 22:05

2 Answers 2

There are plenty of ways for an unprivileged user to slow down a system and running sync is far from being the more efficient. On the other hand, having the file systems data committed to disk is quite a legitimate request so forbidding users (and thus their processes) to do it would be excessive.

In any case, I disagree about your "unnecessary disk writes" statement. These writes are certainly necessary and will automatically happen after a small period of time anyway.

There is even no guarantee the sync call will do anything particular at all depending on its implementation. Calling sync, is, as the POSIX standard defines, only a "suggestion" for the OS to flush its file system caches, it doesn't necessarily force the flushes to happen immediately. More precisely, the calls ask the OS to schedule a cache flush but there is no guarantee it will happen before the already scheduled time although Linux implementation does wait for it to happen before returning.

Moreover, calling sync multiple times in a row would not slow down systems that much, as once the caches are flushed, if no process is actively writing to files the caches are empty so sync is a no-op.

Should you really want to prevent users to run sync on your system, you can just run these commands:

mv /bin/sync /bin/.sync
ln /bin/true /bin/sync

That would largely be unnoticed by users and has no negative effects except with people that just run sync then remove storage devices (eg: usb thumbdrive) without unmounting them, but these users were already acting foolishly anyway.

Note that I wouldn't recommend the previous /bin/sync link with /bin/true. sync is certainly useful in some cases. For example if you fear a brutal shutdown (power shortage, system panic, ...) might happen shortly, that would help preserving the file systems content. This is what I call a legitimate request.

share|improve this answer
2  
@jippie All the sync binary does is call the sync() function, so (like Bonsi Scott said) what you're really asking is why the kernel lets unprivileged users call sync() –  Michael Mrozek Dec 2 '12 at 0:06
2  
@jippie I think you're missing the point. All sync ever does is commit (immediately) to disk things that were going to have to be committed anyway. When I go to remove a flash drive, I want to make sure that everything I wrote to it actually got written. And, while umount is supposed to guarantee this, I'm not assured, so I want (as a user) to make sure before I yank it. There is NO HARM WHATSOEVER in forcing the system to flush buffers to disk. At worst, some things are lagged for a second while the system actively flushes the buffers. The hazard would be in denying users this function. –  killermist Dec 2 '12 at 1:11
2  
@killermist: sync is not forcing, just suggesting. Sync might return with a success exit status without having flushed anything to the disk, not to mention the disk itself might also delay writes under the hood. While I generally share the opinion Windows is missing necessary features, a sync command would the least of my concerns. –  jlliagre Dec 2 '12 at 1:23
2  
@killermist @jippie is correct. You should better trust umount, which, whatever the OS, always flushes the buffers (unless the disk is gone ...) instead of sync which isn't guaranteed to do it depending on the OS. Note that Linux sync waits for the flush to be effective so can be trusted too. –  jlliagre Dec 2 '12 at 9:44
1  
@jlliagre I think your "not forcing, just suggesting" point is enlightening and could be edited into your answer. –  donothingsuccessfully Dec 2 '12 at 10:31

sync cannot do any harm to the system. It can slow it down, but not more so than running programs that access the disk. Why should it be restricted?

There is a good reason to allow any user to run sync. This is necessary if some operations must be performed in order even if the system crashes or loses power. For example, consider a mail transfer agent which receives an email. Once it has written the file containing the email into the spool, it calls sync, and only then does it reply to the sending machine notifying it that the email has been received. If it didn't call sync, and the receiving machine lost power just after sending the reception notification but before committing the file to disk, then the email would be lost.

Operating systems delay disk writes for efficiency. They cannot know when an application really needs the write to happen. So applications are given a way to tell the operating system to write now, with sync(1) and sync(2) and fsync(2).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.