On Wed, Jul 01, 2026 at 11:26:22 -0600, D. R. Evans wrote:

Following an update from bookworm to trixie on one system, my regular user account is no longer able to edit its crontab file on that system.

When I execute "crontab -e", I receive the message: "No modification made" and an editor opens on a blank file.

The user's crontab file does exist:

sudo ls -al /var/spool/cron/crontabs shows:
-rw------- 1 n7dr crontab 2981 Sep 2 2023 n7dr

and, indeed, that file seems to be being processed correctly by cron. But I just can't read and edit it with "crontab -e" :-(

I have no idea why this system is different: the problem doesn't occur on
two other systems that have been upgraded.

Check the permissions on /usr/bin/crontab. It should be setgid crontab.

hobbit:~$ ls -l /usr/bin/crontab
-rwxr-sr-x 1 root crontab 51936 Jun 13 2025 /usr/bin/crontab*

If that's not it, then look for /etc/cron.{allow,deny} files.

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

D. R. Evans (HE12026-07-01):

When I execute "crontab -e", I receive the message: "No modification made" and an editor opens on a blank file.

This specific sequence of events points to a possible cause. Normal
operation is:

1. crontab invokes editor;
2. editor lets you edit the file;
3. you save an quit;
4. editor exits;
5. crontab uses the edited file.

Looks like for you it's happening that way:

1. crontab invokes editor;
4. editor exits;
5. crontab uses the unedited file;
2. editor lets you edit the file;
3. you save an quit.

That can happen if your editor forks or if it is a remote control for an already existing editor. Either way, it is not a correct behavior for
something configured as default editor on a Unix system.

So my advice is: find out exactly which editor you are using and how it behaves.

Regards,

--
Nicolas George

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 1 Jul 2026 11:26:22 -0600
"D. R. Evans" <doc.evans@gmail.com> wrote:

When I execute "crontab -e", I receive the message: "No modification
made" and an editor opens on a blank file.

What editor are you expecting? Where does it show up, and is it showing
up where you expect it to show up? How are you specifying your choice
of editors to crontab?

The man page for crontab says, in part,

The -e option is used to edit the current crontab using
sensible-editor(1).

The man page for sensible-editor indicates where it looks and in what
order. I suggest you check those places, and in that order.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

01.07.26, 19:26 +0200, D. R. Evans:

Following an update from bookworm to trixie on one system, my regular user account is no longer able to edit its crontab file on that system.

When I execute "crontab -e", I receive the message: "No modification made" and
an editor opens on a blank file.

What exactly is "an editor" in this case?

--
Regards
mks

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 1 Jul 2026 15:27:37 -0600
"D. R. Evans" <doc.evans@gmail.com> wrote:

On the machine where it works, I have VISUAL='/usr/bin/kate -b -n'...
and... if I do exactly the same on the machine that I just upgraded,
"crontab -e" suddenly works. Yay!!! Dark magic!

Odd. According to apt-file, the executable for kate is where you show
it, /usr/bin. There are plenty of other useful executables there. So
that should be in your path. However, crontab may clear the path (or not inherit it). Have you exported it?

In any case, using the fully qualified path is usualy a good practice.

I'm glad that solved your problem.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, Jul 01, 2026 at 18:55:28 -0600, Charles Curley wrote:

On Wed, 1 Jul 2026 15:27:37 -0600
"D. R. Evans" <doc.evans@gmail.com> wrote:

On the machine where it works, I have VISUAL='/usr/bin/kate -b -n'... and... if I do exactly the same on the machine that I just upgraded, "crontab -e" suddenly works. Yay!!! Dark magic!

Odd. According to apt-file, the executable for kate is where you show
it, /usr/bin. There are plenty of other useful executables there. So
that should be in your path. However, crontab may clear the path (or not inherit it). Have you exported it?

In any case, using the fully qualified path is usualy a good practice.

I'm glad that solved your problem.

It's not the path that mattered. It's the -b option, which (according
to the man page I found on Debian's web site) tells the Kate command
line process to block and wait for the editor instance to finish before exiting.

Without -b, we can deduce that the Kate command line process is
sending the edit request to an "already running Kate instance", and
then terminating, at which point crontab checks the file, sees no
change, and reports the lack of changes, leaving the installed crontab unchanged.

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Greg Wooledge (HE12026-07-01):

Without -b, we can deduce that the Kate command line process is
sending the edit request to an "already running Kate instance", and
then terminating, at which point crontab checks the file, sees no
change, and reports the lack of changes, leaving the installed crontab unchanged.

So I was right. Good.

Regards,

--
Nicolas George

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, Jul 02, 2026 at 05:33:57 -0600, D. R. Evans wrote:

Greg Wooledge wrote on 7/1/26 8:19 PM:

Without -b, we can deduce that the Kate command line process is
sending the edit request to an "already running Kate instance", and
then terminating, at which point crontab checks the file, sees no
change, and reports the lack of changes, leaving the installed crontab unchanged.

Yes... except that I wasn't using any other instance of kate, so it's still not entirely clear (to me, anyway) why I had to change the value of $VISUAL. [Something to do with the way the editor is invoked by crontab, perhaps?]

I now have this issue filed in my voluminous mental "I don't understand
this, but I have other things I need to worry about" file.

Try running "kate -n" or maybe "kate -n /tmp/xxx" in a terminal and see
what happens. Does it open a GUI window and then give you a new shell
prompt in the terminal immediately?

Then, try adding the -b option and see how that changes the behavior.

--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, Jul 02, 2026 at 05:33:57AM -0600, D. R. Evans wrote:

Greg Wooledge wrote on 7/1/26 8:19 PM:

Without -b, we can deduce that the Kate command line process is
sending the edit request to an "already running Kate instance", and
then terminating, at which point crontab checks the file, sees no
change, and reports the lack of changes, leaving the installed crontab unchanged.

Yes... except that I wasn't using any other instance of kate [...]

You were, you just didn't know: kate was helpfully doing that for you :)
As Greg explains in another post, what happens is that crontab invokes
an editor and waits until that process returns. Then it "knows" you
are done editing, picks up the modified file and installs it in
place.
Kate (without the -b option) breaks that expectation by returning
immediately (crontab "thinks" you are done) and continuing "in the
background" (from the POV of crontab) letting you edit the file.
At that point in time, crontab has already picked up the (yet
unmodified) file. Any modifications you may make are lost, since
too late.
Cheers
--
t


--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)